Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade

David Rowley <dgrowleyml@gmail.com>

From: David Rowley <dgrowleyml@gmail.com>

To: Yuri Zamyatin <yuri@yrz.am>, Amit Langote <amitlangote09@gmail.com>

Cc: Jeff Davis <pgsql@j-davis.com>, pgsql-bugs@lists.postgresql.org

Date: 2025-10-15T22:51:35Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix reset of incorrect hash iterator in GROUPING SETS queries
- 0b6a02f0355c 18.1 landed
- 5c0a20003b43 19 (unreleased) landed
Fix EPQ crash from missing partition directory in EState
- 1296dcf18b1c 18.1 landed
- 905e932f0922 19 (unreleased) landed

On Thu, 16 Oct 2025 at 11:45, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Thu, 16 Oct 2025 at 03:21, Yuri Zamyatin <yuri@yrz.am> wrote:
> > In 1-2 minutes, 5 processes died with segfault.
>
> Perfect. Thank you.
>
> It seems to be some more forgotten EPQ stuff from d47cbf474.  Amit got
> some of these in 8741e48e5, but evidently the test case didn't do
> pruning during execution, (only init plan pruning) so the partition
> directory wasn't needed.

I forgot to mention, this isn't the same thing as the
tts_minimal_store_tuple() issue you first reported, so if there is a
problem there, this one has nothing to do with it.

Any chance of a self-contained test case for the enable_hashagg=on crash?

David