Horton

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

David Rowley <dgrowleyml@gmail.com>

View thread
From: David Rowley <dgrowleyml@gmail.com>
To: Yuri Zamyatin <yuri@yrz.am>
Cc: Jeff Davis <pgsql@j-davis.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-10-12T08:10:13Z
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 →

  1. Fix reset of incorrect hash iterator in GROUPING SETS queries

  2. Fix EPQ crash from missing partition directory in EState

On Fri, 10 Oct 2025 at 14:34, Yuri Zamyatin <yuri@yrz.am> wrote:
>
> Hi. I was able to reproduce the crash with the simpler (non hash-agg) plan from the previous message.
> Basically I launched it in multiple infinite loops that do BEGIN - UPDATE - ROLLBACK. Other clients could also modify the tables during this time.
> We've seen this query crash on multiple physical hosts.

> > #0  0x0000555fe8678300 in PartitionDirectoryLookup (pdir=0x0, rel=0x7f14d172b288) at ./build/../src/backend/partitioning/partdesc.c:462
> >         pde = <optimized out>
> >         relid = 21856
> >         found = 27

Looks like that's crashing in a different place from the last
backtrace you showed.

Are you able to test this without any extensions loaded to see if you
still get a crash?

At a wild guess, perhaps an extension has gone rogue and spawned
another thread resulting in something like concurrent palloc requests
getting confused and causing something strange to happen when
accessing certain palloc'd chunks. Running without extensions may help
narrow things down.

> postgresql_effective_cache_size = 560GB
> postgresql_shared_buffers = 225GB

Which extension are these GUCs from?

David