Re: Assertion failure in SnapBuildInitialSnapshot()

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Assertion failure in SnapBuildInitialSnapshot()
Дата
Msg-id CAA4eK1Ki2Czu8rQ6ZidSqoJHAuqXWBSk1_9avP=aee1u1ejGGw@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Assertion failure in SnapBuildInitialSnapshot()  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Ответы Re: Assertion failure in SnapBuildInitialSnapshot()
Список pgsql-hackers
On Fri, Nov 21, 2025 at 9:17 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Thursday, November 13, 2025 12:56 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote:
> >
>
> I have been thinking if there a way to avoid holding ReplicationSlotControlLock
> exclusively in ReplicationSlotsComputeRequiredXmin() because that could cause
> lock contention when many slots exist and advancements occur frequently.
>
> Given that the bug arises from a race condition between slot creation and
> concurrent slot xmin computation, I think another way is that, we acquire the
> ReplicationSlotControlLock exclusively only during slot creation to do the
> initial update of the slot xmin. In ReplicationSlotsComputeRequiredXmin(), we
> still hold the ReplicationSlotControlLock in shared mode until the global slot
> xmin is updated in ProcArraySetReplicationSlotXmin(). This approach prevents
> concurrent computations and updates of new xmin horizons by other backends
> during the initial slot xmin update process, while it still permits concurrent
> calls to ReplicationSlotsComputeRequiredXmin().
>

Yeah, this seems to work.

> Here is an update patch for this approach on HEAD.
>

Thanks for the patch.

Sawada-San, are you planning to look into this? Otherwise, I can take
care of it.

--
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления: