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()  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Assertion failure in SnapBuildInitialSnapshot()
Следующее
От: Nitin Jadhav
Дата:
Сообщение: Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl