Re: How can end users know the cause of LR slot sync delays?
От | Ashutosh Sharma |
---|---|
Тема | Re: How can end users know the cause of LR slot sync delays? |
Дата | |
Msg-id | CAE9k0Pm1csRx4sALOgvwWHUnx-8bAa+NFxnbhcwU8hPcJPLF+Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How can end users know the cause of LR slot sync delays? (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: How can end users know the cause of LR slot sync delays?
|
Список | pgsql-hackers |
Hi Amit, On Fri, Sep 12, 2025 at 4:24 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Sep 12, 2025 at 1:07 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote: > > > > On Mon, Sep 8, 2025 at 9:52 AM Ashutosh Sharma <ashu.coek88@gmail.com> wrote: > > > > > > I think we can do that, since sync_skip_reason appears to be a > > > descriptive metadata rather than statistical data like > > > slot_sync_skip_count and last_slot_sync_skip. However, it's also true > > > that all three pieces of data are transient by nature - they will just > > > be present in the runtime. > > > > > > > After spending some more time on this, I found that maintaining > > sync_skip_reason in pg_replication_slots would make the code changes a > > bit messy and harder to maintain. > > > > What exactly is your worry? It seems more logical to have > sync_skip_reason in pg_replication_slots and other two in > pg_stat_replication_slots as the latter is purely a stats view and the > sync_skip_count/last_sync_skip suits there better. > The code changes for adding the skip reason to pg_replication_slots feel a bit hacky compared to the approach for incorporating all three pieces of information in pg_stat_replication_slots. I thought many might prefer simplicity over hackiness, which is why having everything in pg_stat_replication_slots could be more acceptable. That said, we could maybe prepare a POC patch with this approach as well, compare the two, and then decide which path to take. -- With Regards, Ashutosh Sharma.
В списке pgsql-hackers по дате отправления: