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 по дате отправления: