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