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@postgresql.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