Re: BUG #17737: An assert failed in execExprInterp.c

Hi,

On 2023-01-05 15:50:03 -0500, Tom Lane wrote:
> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > When executing the following query:
>
> > CREATE TABLE table0 ( column1 INT ) ;
> > INSERT INTO table0 VALUES ( 1 ), ( 1 ) ;
> > WITH RECURSIVE table3 ( column0 ) AS ( SELECT column1 FROM table0 UNION
> > SELECT column0 FROM table3 WHERE column0 < 1 ) SELECT 1 FROM table3 LEFT
> > JOIN table0 ON TRUE ;
>
> > I get a failed assertion with the following stacktrace:
>
> Yeah. The problem is that LookupTupleHashEntry is being handed
> a BufferHeapTuple slot, evidently direct from the scan of table0,
> but BuildTupleHashTableExt previously set up the comparison
> expression on the assumption that the input would be a MinimalTuple
> slot:
>
> /* build comparator for all columns */
> /* XXX: should we support non-minimal tuples for the inputslot? */
> hashtable->tab_eq_func = ExecBuildGroupingEqual(inputDesc, inputDesc,
> &TTSOpsMinimalTuple, &TTSOpsMinimalTuple,
> ...
>
> AFAICT this has been wrong since we introduced multiple slot types
> (I bisected it back to 15d8f8312, but of course that's just the
> messenger).

> I'm kind of baffled as to how it's escaped detection for this long;
> maybe the assertion is overly tight, and the case actually works
> in non-assert builds?

I suspect it might work solely because the columns happen to have already been
deformed. At least that's the case in the example above.

I'll be in a meetings for the next bit, will take a closer look after.

Greetings,

Andres Freund