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: Richard Guo <guofenglinux@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, Paul Ramsey <pramsey@cleverelephant.ca>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>

Date: 2024-12-18T23:10:00Z

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

David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 18 Dec 2024 at 23:45, David Rowley <dgrowleyml@gmail.com> wrote:
>> Maybe we need to backpatch passing NULL instead of &TTSOpsMinimalTuple
>> to ExecBuildGroupingEqual() in BuildTupleHashTableExt(). Something
>> like the attached patch.

> I've attached a more formal patch for this and I've also now done a
> bit more research and experimentation as to why we didn't notice this
> for so long.

I suspect that another key reason for the lack of reports is that
it's an assertion failure only, with no consequences in production
builds.  So ordinary users issuing such a query wouldn't notice.

> I propose to quickly do a master-only follow-up commit to use the
> inputOps instead of NULL in BuildTupleHashTableExt (Basically Tom's
> patch from [1])

LGTM.

			regards, tom lane