Re: Pg18 Recursive Crash

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

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

To: Richard Guo <guofenglinux@gmail.com>

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

Date: 2024-12-19T00:22:40Z

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

Richard Guo <guofenglinux@gmail.com> writes:
> I see.  I didn't notice any real issues with that; I was just flagged
> by the XXX comment there, which raises the question of whether it's
> worth working harder to determine the inputOps.

I was intending to add some code to my nodeSetop patch to see if
both input plan nodes use the same fixed slot type, and if so
pass that rather than NULL to BuildTupleHashTableExt.  Perhaps
nodeRecursiveunion could do the same thing (in which case we
probably ought to abstract that out to a subroutine).

			regards, tom lane