Re: Assertion failure in SnapBuildInitialSnapshot()
От | Amit Kapila |
---|---|
Тема | Re: Assertion failure in SnapBuildInitialSnapshot() |
Дата | |
Msg-id | CAA4eK1KDE0xaC1YgHzSUQ3yVvQv+CY96UOB7CRdaSw2CHeXu7w@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Assertion failure in SnapBuildInitialSnapshot() ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
Re: Assertion failure in SnapBuildInitialSnapshot()
|
Список | pgsql-hackers |
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.". 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. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: