Re: Pg18 Recursive Crash

David Rowley <dgrowleyml@gmail.com>

From: David Rowley <dgrowleyml@gmail.com>

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

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

Date: 2024-12-18T01:52:05Z

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

On Wed, 18 Dec 2024 at 14:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So I tried adapting my patch to not make a copy of the input slot,
> and it didn't work: I was still getting assertion failures about
> the slot not being a MinimalTupleSlot as expected.  On investigation
> 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? Your
patch adjusts code that existed prior to d96d1d515, so I'm confused as
to why your patch is needed now when it wasn't before.

If you're only triggering an issue after patching with your setops
patch, are your changes maybe using FindTupleHashEntry() with an
eqcomp that isn't compatible with the 'slot' parameter you're passing
to that function?

David