Re: Improve pg_sync_replication_slots() to wait for primary to advance
От | shveta malik |
---|---|
Тема | Re: Improve pg_sync_replication_slots() to wait for primary to advance |
Дата | |
Msg-id | CAJpy0uDsoaJLeKz7GMjy+ZR7fHE3r8wZrn+jp+nHHSjCXKvt2A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improve pg_sync_replication_slots() to wait for primary to advance (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Thu, Oct 9, 2025 at 2:14 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Tue, Oct 7, 2025 at 5:13 PM shveta malik <shveta.malik@gmail.com> wrote: > > > > On Tue, Oct 7, 2025 at 4:49 PM Ashutosh Bapat > > <ashutosh.bapat.oss@gmail.com> wrote: > > > > > > Shorter nap times mean higher possibility of wasted CPU cycles - that > > > should be avoided. Doing that for a test's sake seems wrong. Is there > > > a way that the naptime can controlled by external factors such as > > > likelihood of an advanced slot (just firing bullets in the dark) or is > > > the naptime controllable by user interface like GUC? The test can use > > > those interfaces. > > > > > > > Yes, we can control naptime based on the fact whether any slots are > > being advanced on primary. This is how a slotsync worker does. It > > keeps on doubling the naptime if there is no activity on primary > > starting from 200ms till max of 30 sec. As soon as activity happens, > > naptime is reduced to 200ms again. > > > > Is there a reason why we don't want to use the same naptime strategy > for API and worker? > There was a suggestion at [1] for a shorter naptime in case of API. [1]: https://www.postgresql.org/message-id/CAExHW5sQLJGhEA%2B9ZFVwZUpqfFFP5KPn9w64t3uiHSuiEH-9mQ%40mail.gmail.com thanks Shveta
В списке pgsql-hackers по дате отправления: