Re: Conflict detection for update_deleted in logical replication
От | Amit Kapila |
---|---|
Тема | Re: Conflict detection for update_deleted in logical replication |
Дата | |
Msg-id | CAA4eK1+6dMtNsX_XMmoYWyv9ZKUCS0pi9YsC+KZoM5o_4tQ1yg@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Conflict detection for update_deleted in logical replication ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
Ответы |
RE: Conflict detection for update_deleted in logical replication
|
Список | pgsql-hackers |
On Fri, Sep 12, 2025 at 8:55 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > I agree. Here is a V73 patch that will restart the worker if the retention > resumes. I also addressed other comments posted by Amit[1]. > Few comments: ============ * In adjust_xid_advance_interval(), for the case when retention is not active, we still cap the interval by wal_receiver_status_interval. Is that required or do we let it go till 3 minutes? We can add a new else if loop to keep the code clear, if you agree with this. * + /* + * Resume retention immediately if required. (See + * should_resume_retention_immediately() for details). + */ + if (should_resume_retention_immediately(rdt_data, status_received)) + rdt_data->phase = RDT_RESUME_CONFLICT_INFO_RETENTION; Is this optimization for the case when we are in stop_phase or after stop_phase and someone has changed maxretention to 0? If so, I don't think it is worth optimizing for such a rare case at the cost of making code difficult to understand. Apart from this, I have changed a few comments in the attached. -- With Regards, Amit Kapila.
Вложения
В списке pgsql-hackers по дате отправления: