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
thetables 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
