Re: Newly created replication slot may be invalidated by checkpoint
| От | Amit Kapila |
|---|---|
| Тема | Re: Newly created replication slot may be invalidated by checkpoint |
| Дата | |
| Msg-id | CAA4eK1J6WKZbQv2MqyShynSAiV8nT6R62_hPUzvjfD7moWiD8Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Newly created replication slot may be invalidated by checkpoint (Alexander Korotkov <aekorotkov@gmail.com>) |
| Список | pgsql-hackers |
On Thu, Dec 18, 2025 at 5:41 PM Alexander Korotkov <aekorotkov@gmail.com> wrote: > > On Thu, Dec 11, 2025 at 9:29 AM Zhijie Hou (Fujitsu) > <houzj.fnst@fujitsu.com> wrote: > > On Thursday, December 11, 2025 3:09 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > > I reviewed that approach, and I think the main distinction lies in whether to > > > use a new LWLock to serialize the process or rely on an existing lock. > > > Introducing a new LWLock in back branches would alter the size of > > > MainLWLockArray and affect > > > NUM_INDIVIDUAL_LWLOCKS/LWTRANCHE_FIRST_USER_DEFINED. > > > Although this may not directly impact user applications since users typically > > > use standard APIs like RequestNamedLWLockTranche and > > > LWLockNewTrancheId to add private LWLocks, it still has a slight risk. > > > Additionally, using an existing lock could keep code similarity with the HEAD, > > > which can be helpful for future bug fixes and analysis. > > > > BTW, I searched the git history and can only find 2 old commits that adds lwlock > > On stable branches, but both of are fixing serious problems such as > > data corruption / loss issues. > > I understand that that was done due to more serious reasons than ours. > As I get, it run smoothly. At least, I can't remember we have been > reported with any issues regarding to this change. Can we assume this > is kind of "tested" and add new LWLock to both master and back > branches? I think this would be good in terms of clarity and minimal > possible divergence of back branches. > The impact of using the new lock on master is more because we need to start using it in CheckPointReplicationSlots() to protect the WAL reservation. Then, we also probably need to use new lock in create/drop slot APIs. Or we can start using this new lock in addition to ReplicationSlotAllocationLock in CheckPointReplicationSlots(). Yet another possibility is to use a new lock while computing RedoRecPtr in CreateCheckPoint. I am not sure that is an improvement for master as compared to the way it is currently working. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: