From: Tom Lane <tgl@sss.pgh.pa.us>
To: xinwen@stu.scu.edu.cn
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17737: An assert failed in execExprInterp.c
Date: Thu, 05 Jan 2023 15:50:03 -0500
Message-ID: <2811897.1672951803@sss.pgh.pa.us> (raw)
In-Reply-To: <17737-55a063e3e6c41b4f@postgresql.org>
References: <17737-55a063e3e6c41b4f@postgresql.org>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, xinwen@stu.scu.edu.cn, andres@anarazel.de, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17737: An assert failed in execExprInterp.c
In-Reply-To: <2811897.1672951803@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox