Re: Pg18 Recursive Crash

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: David Rowley <dgrowleyml@gmail.com>

Cc: Nathan Bossart <nathandbossart@gmail.com>, Paul Ramsey <pramsey@cleverelephant.ca>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>

Date: 2024-12-18T02:28:57Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Optimize grouping equality checks with virtual slots
- 08cdb079d4a8 18.0 landed
Fix Assert failure in WITH RECURSIVE UNION queries
- 2c7887c9d612 13.19 landed
- bdb07d24113b 14.16 landed
- ef178d38bb49 15.11 landed
- 093fc156b0ef 16.7 landed
- 7b8d45d278de 17.3 landed
- 8f4ee962691e 18.0 landed
Fix incorrect slot type in BuildTupleHashTableExt
- d96d1d5152f3 18.0 landed

Attachments

wip-setop-improvements.patch (text/x-diff) patch

David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 18 Dec 2024 at 14:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> it appears your patch did not fully adjust BuildTupleHashTableExt
>> for variable input-slot type.  You need the attached as well.

> Do you have a test case in master that triggers a problem here?

No, that's what I didn't want to spend time looking for ;-).
But here is a WIP modification of my 0001 patch from the SetOp
improvement thread -- the difference is to lobotomize
setop_load_hash_tuple to just return the input slot.  Without
the execGrouping.c changes, it gets assertion failures in the core
regression tests.  (My intention had been to remove
setop_load_hash_tuple and then adjust build_hash_table to
pass a non-null inputOps if the two inputs have the same tuple
slot type.  But I got stuck on this step.)

			regards, tom lane