Re: Pg18 Recursive Crash

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pg18 Recursive Crash
Date: 2024-12-18 22:21:27
Message-ID: CAApHDvrEr3ySL7V-ydSj3+ZFvjPc_Quodhoazp_A-7gM=s-7RQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 18 Dec 2024 at 23:45, David Rowley <dgrowleyml(at)gmail(dot)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. It looks like the non-recursive part of the UNION must
use TTSOpsBufferHeapTuple and there must be duplicates. So that
basically means you need to select all columns, otherwise, there'd be
projection and the slot would be virtual. That boils down to, you need
a table without a primary key or any unique constraints, otherwise,
you can't get the duplicate value that's required to trigger the
Assert failure. I hope the proposed commit message is enough to
explain this in enough detail.

Of course, there may maybe some other path to trigger this using one
of the other users of BuildTupleHashTableExt().

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])

Sound ok?

David

[1] https://postgr.es/m/2543667.1734483723@sss.pgh.pa.us

Attachment Content-Type Size
v1-0001-Fix-Assert-failure-in-WITH-RECURSIVE-UNION-querie.patch application/octet-stream 4.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-12-18 23:06:28 Re: Regression tests fail on OpenBSD due to low semmns value
Previous Message Robert Haas 2024-12-18 21:29:50 Re: Eagerly scan all-visible pages to amortize aggressive vacuum