Re: Assertion failure in SnapBuildInitialSnapshot()
От | Masahiko Sawada |
---|---|
Тема | Re: Assertion failure in SnapBuildInitialSnapshot() |
Дата | |
Msg-id | CAD21AoANp_bfSntdL29cH6PwTVX91H4ws=PxqX2V9iLK-hjz4g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assertion failure in SnapBuildInitialSnapshot() (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Assertion failure in SnapBuildInitialSnapshot()
|
Список | pgsql-hackers |
On Mon, Jan 30, 2023 at 8:30 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Jan 27, 2023 at 4:31 PM Hayato Kuroda (Fujitsu) > <kuroda.hayato@fujitsu.com> wrote: > > > > Thank you for making the patch! I'm still considering whether this approach is > > correct, but I can put a comment to your patch anyway. > > > > ``` > > - Assert(!already_locked || LWLockHeldByMe(ProcArrayLock)); > > - > > - if (!already_locked) > > - LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); > > + Assert(LWLockHeldByMe(ProcArrayLock)); > > ``` > > > > In this function, we regard that the ProcArrayLock has been already acquired as > > exclusive mode and modify data. I think LWLockHeldByMeInMode() should be used > > instead of LWLockHeldByMe(). > > > > Right, this is even evident from the comments atop > ReplicationSlotsComputeRequiredXmin("If already_locked is true, > ProcArrayLock has already been acquired exclusively.". Agreed, will fix in the next version patch. > But, I am not > sure if it is a good idea to remove 'already_locked' parameter, > especially in back branches as this is an exposed API. Yes, we should not remove the already_locked parameter in backbranches. So I was thinking of keeping it on back branches. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: