search

trinodb / trino

Official repository of Trino, the distributed SQL query engine for big data, formerly known as PrestoSQL (https://trino.io)
https://trino.io
Apache License 2.0
9.85k stars 2.85k forks source link

java.lang.NoSuchMethodError: 'io.trino.spi.block.ValueBlock io.trino.spi.block.DictionaryBlock.getDictionary(int)' #21002

Closed erikamundson closed 3 months ago

erikamundson commented 3 months ago

Hi, I'm getting this error on Trino 440 (this is the full trace).

Has happened on a couple queries so far. They're pretty large queries so I'm not sure what operation it's coming from but will update with more info. This is using the Delta Lake connector if that matters.

java.lang.NoSuchMethodError: 'io.trino.spi.block.ValueBlock io.trino.spi.block.DictionaryBlock.getDictionary(int)'
    at io.trino.$gen.AggregationMaskBuilder_20240310_210455_1010.buildAggregationMask(Unknown Source)
    at io.trino.operator.aggregation.GroupedAggregator.processPage(GroupedAggregator.java:83)
    at io.trino.operator.aggregation.builder.InMemoryHashAggregationBuilder.lambda$processPage$1(InMemoryHashAggregationBuilder.java:157)
    at io.trino.operator.TransformWork.process(TransformWork.java:44)
    at io.trino.operator.HashAggregationOperator.addInput(HashAggregationOperator.java:443)
    at io.trino.operator.Driver.processInternal(Driver.java:403)
    at io.trino.operator.Driver.lambda$process$8(Driver.java:301)
    at io.trino.operator.Driver.tryWithLock(Driver.java:704)
    at io.trino.operator.Driver.process(Driver.java:293)
    at io.trino.operator.Driver.processForDuration(Driver.java:264)
    at io.trino.execution.SqlTaskExecution$DriverSplitRunner.processFor(SqlTaskExecution.java:887)
    at io.trino.execution.executor.dedicated.SplitProcessor.run(SplitProcessor.java:76)
    at io.trino.execution.executor.dedicated.TaskEntry$VersionEmbedderBridge.lambda$run$0(TaskEntry.java:191)
    at io.trino.$gen.Trino_440____20240310_204818_2.run(Unknown Source)
    at io.trino.execution.executor.dedicated.TaskEntry$VersionEmbedderBridge.run(TaskEntry.java:192)
    at io.trino.execution.executor.scheduler.FairScheduler.runTask(FairScheduler.java:174)
    at io.trino.execution.executor.scheduler.FairScheduler.lambda$submit$0(FairScheduler.java:161)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
    at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:131)
    at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:76)
    at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:82)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
    at java.base/java.lang.Thread.run(Thread.java:1583)
erikamundson commented 3 months ago

I was able to narrow it down to the query below. In this case cell_id and step_type are string columns. update_ts is a timestamp with time zone. It seems be related to the filter clause because it works when I take that out.

The table is around 5B rows (and larger than the query.max-memory limit) if that makes a difference. 

select 
    cell_id, 
    max(update_ts) filter (where step_type = 'Rest') as last_rest_update
from delta.cycling.details
group by cell_id
wendigo commented 3 months ago

@dain can you take a look?

findepi commented 3 months ago

Self contained repro

select 
    cell_id, 
    max(update_ts) filter (where step_type = 'Rest')
FROM (
    VALUES 
        ('cell_id', 'Rest', current_timestamp(3)),
        ('cell_id', 'Rest', current_timestamp(3))
    ) AS t(cell_id, step_type, update_ts)
CROSS JOIN UNNEST (sequence(1, 1000)) AS a(e)
group by cell_id;
findepi commented 3 months ago

@erikamundson can you please check whether https://github.com/trinodb/trino/pull/21049 fixes the problem for you?

erikamundson commented 3 months ago

@findepi I'm not able to test this on our actual data currently, but it does fix your self-contained reproduction so I think it should fix our problem as well.