Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
От | David Rowley |
---|---|
Тема | Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade |
Дата | |
Msg-id | CAApHDvriuYHvGcuci+h6kMc306DgHkfTbro53AU=3UokpSOSOw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade (Yuri Zamyatin <yuri@yrz.am>) |
Ответы |
Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: