prestodb/presto · error · ParquetDecodingException

not a valid mode

Error message

not a valid mode 

What it means

TimestampRLEDictionaryValuesDecoder.readNext() decodes INT96 timestamp dictionary indices into packed long timestamp values, switching over the run's MODE. The default branch throws ParquetDecodingException("not a valid mode " + mode) when the run mode decoded from the page header is not one of the supported modes. As with the other RLE dictionary decoders, the mode comes from the RLE hybrid header's low bit, so this signals a malformed, truncated, or misaligned data page in a timestamp column chunk.

Source

Thrown at presto-parquet/src/main/java/com/facebook/presto/parquet/batchreader/decoders/rle/TimestampRLEDictionaryValuesDecoder.java:77

            switch (mode) {
                case RLE: {
                    final int rleValue = currentValue;
                    final long rleValueMillis = dictionary.decodeToLong(rleValue);
                    while (destinationIndex < endIndex) {
                        values[destinationIndex++] = rleValueMillis;
                    }
                    break;
                }
                case PACKED: {
                    final int[] localBuffer = currentBuffer;
                    final TimestampDictionary localDictionary = dictionary;
                    for (int srcIndex = currentBuffer.length - currentCount; destinationIndex < endIndex; srcIndex++) {
                        values[destinationIndex++] = localDictionary.decodeToLong(localBuffer[srcIndex]);
                    }
                    break;
                }
                default:
                    throw new ParquetDecodingException("not a valid mode " + mode);
            }

            currentCount -= numEntriesToFill;
            remainingToCopy -= numEntriesToFill;
        }
        checkState(remainingToCopy == 0, "End of stream: Invalid read size request");
    }

    @Override
    public void skip(int length)
            throws IOException
    {
        checkArgument(length >= 0, "invalid length %s", length);
        int remaining = length;
        while (remaining > 0) {
            if (currentCount == 0) {
                if (!decode()) {
                    break;

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Check file integrity with parquet-tools and regenerate the file if the timestamp column chunk is damaged.
  2. Upgrade Presto; several timestamp batch-reader header parsing bugs were fixed in later releases.
  3. Rewrite the table with a supported timestamp logical type (TIMESTAMP_MICROS/TIMESTAMP_MILLIS instead of INT96) if the writer supports it.
  4. Fall back to the non-batch reader path for this file/column.

Example fix

// before
decoder.readNext(values, offset, length); // throws 'not a valid mode ...'

// after: fail with context instead of raw decoder error
try {
    decoder.readNext(values, offset, length);
} catch (ParquetDecodingException e) {
    throw new PrestoException(PARQUET_CORRUPT_DATA,
        "Invalid RLE mode in timestamp column " + column + " of " + path, e);
}
Defensive patterns

Strategy: try-catch

Validate before calling

// Validate footer and page-level metadata before decoding
ParquetMetadata meta = MetadataReader.readFooter(dataSource, fileSize);
checkArgument(!meta.getBlocks().isEmpty(), "No row groups in " + dataSource.getId());

Try / catch

try {
    decoder.readNext(values, offset, length);
} catch (ParquetDecodingException e) {
    throw new PrestoException(PARQUET_CORRUPT_DATA,
        "Invalid RLE mode in timestamp column " + column, e);
}

Prevention

When it happens

Trigger: Public readNext() processes a run whose mode is unsupported — a bad or truncated RLE header in an INT96/timestamp dictionary-encoded data page, or a page buffer handed to the decoder at the wrong byte offset.

Common situations: Corrupt or partially written Parquet files; Hive writing INT96 timestamps read by a Presto version with batch-reader parsing bugs; wrong page-offset metadata after compaction; files produced by third-party writers deviating from the Parquet spec.

Related errors


AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/1d661a3ddd23835a. Report an issue: GitHub.