Horton

Re: Pg18 Recursive Crash

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

View thread
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-17T22:04:49Z
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 →

  1. Optimize grouping equality checks with virtual slots

  2. Fix Assert failure in WITH RECURSIVE UNION queries

  3. Fix incorrect slot type in BuildTupleHashTableExt

David Rowley <dgrowleyml@gmail.com> writes:
> The slightly annoying thing here is that the attached patch passes the
> TupleTableSlotOps as NULL in nodeSetOp.c. Per nodeAppend.c line 186,
> Append does not go to much effort to setting a fixed
> TupleTableSlotOps. Really it could loop over all the child plans and
> check if those have fixed slot types of the same type and then fix its
> own resulting slot. For nodeSetOps.c use case, since the planner
> (currently) injects the flag into the target list, it'll always
> project and use a virtual slot type.  It's maybe worth coming back and
> adjusting nodeAppend.c so it works a bit harder to fix its slot type.
> I think that's likely for another patch, however.  Tom is also
> currently working on nodeSetOps.c to change how all this works so it
> no longer uses the flags method to determine the outer and inner
> sides.

Yeah, I see no point in putting effort into improving the current
nodeSetOp implementation.  There might be a reason to change
nodeAppend as you suggest for other use-cases though.

> I plan to push the attached patch soon.

I'll presumably need to rebase my nodeSetOp patch when this goes
in.  I'll take a look then at whether the new code can be improved
with this additional feature.

			regards, tom lane