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? If so I'd be inclined to just weaken
CheckOpSlotCompatibility some more. Otherwise, we need to either
improve execGrouping.c to cope with different input slot types,
or fix nodeRecursiveunion.c to force the supplied slot to be a
minimal one. That last option seems pretty hacky, and it may fail
to cover some other case.
regards, tom lane
