Re: BUG #18559: Crash after detaching a partition concurrently from another session
От | Kuntal Ghosh |
---|---|
Тема | Re: BUG #18559: Crash after detaching a partition concurrently from another session |
Дата | |
Msg-id | CAGz5QC+XXc+rV=BBGwGVoOO8X7hmhpLfNBvVOiZpk22M6PyfBg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18559: Crash after detaching a partition concurrently from another session (Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org>) |
Ответы |
Re: BUG #18559: Crash after detaching a partition concurrently from another session
|
Список | pgsql-bugs |
On Tue, Aug 13, 2024 at 11:49 PM Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org> wrote: > > That means - after getting the live partitions from > > prune_append_rel_partitions(), by the time the code tries to lock a > > child, it's already dropped. > > Right. > > > However, similar check is not there in expand_partitioned_rtentry(). > > Introducing the same check will fix the issue. But, I don't know how > > it affects the pruning part as this partition couldn't be pruned > > earlier and that's why we're opening the child partition. > > Hmm, we could just remove the partition from the set of live partitions > -- then it should behave the same as if the partition had been pruned. > Something like the attached, perhaps. > Thanks for the patch. LGTM. I've verified that it's fixing the issue. -- Thanks & Regards, Kuntal Ghosh
В списке pgsql-bugs по дате отправления: