Re: BUG #18559: Crash after detaching a partition concurrently from another session
От | Junwang Zhao |
---|---|
Тема | Re: BUG #18559: Crash after detaching a partition concurrently from another session |
Дата | |
Msg-id | CAEG8a3L-4qyFUQO=ARZu+=-owVbW8oJziDH0GcU9GYt0__jYvg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18559: Crash after detaching a partition concurrently from another session (Kuntal Ghosh <kuntalghosh.2007@gmail.com>) |
Ответы |
Re: BUG #18559: Crash after detaching a partition concurrently from another session
|
Список | pgsql-bugs |
On Fri, Aug 16, 2024 at 3:32 AM Kuntal Ghosh <kuntalghosh.2007@gmail.com> wrote: > > 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. > +1 > > > -- > Thanks & Regards, > Kuntal Ghosh -- Regards Junwang Zhao
В списке pgsql-bugs по дате отправления: