Re: Improve pg_sync_replication_slots() to wait for primary to advance
От | Dilip Kumar |
---|---|
Тема | Re: Improve pg_sync_replication_slots() to wait for primary to advance |
Дата | |
Msg-id | CAFiTN-uhO+Vb99n1bTSrf8jXCBzbj9VRmXUHcSMvXXYJShJNNg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improve pg_sync_replication_slots() to wait for primary to advance (shveta malik <shveta.malik@gmail.com>) |
Список | pgsql-hackers |
On Fri, Jul 18, 2025 at 11:25 AM shveta malik <shveta.malik@gmail.com> wrote: > > Okay. I see your point. Yes, it was non-blocking earlier but it was > not giving ERROR, it was just dumping in logilfe that primary is > behind and thus slot-sync could not be done. > > If we continue using the non-blocking mode, there’s a risk that the > API may never successfully sync the slots. This is because it > eventually drops the temporary slot on exit, and when it tries to > create a new one later on subsequent call, it’s likely that the new > slot will again be ahead of the primary. This may happen if we have > continuous ongoing writes on the primary and the logical slot is not > being consumed at the same pace. > > My preference would be to avoid including such an option as it is > confusing. With such an option in place, users may think that > slot-sync is completed while that may not be the case. Fair enough But if it's > necessary for backward compatibility, it should be okay to provide it > as a non-default option as you suggested. Would like to know what > others think of this. I think we don't need to maintain backward compatibility here as it was not behaving sanely before, so I am fine with providing the behaviour we are doing with the patch. -- Regards, Dilip Kumar Google
В списке pgsql-hackers по дате отправления: