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 | CAE9k0P=FT6FrrjTg=wppvCCN21xmOxzGB1biJ37-+b=d+uE0-A@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 Wed, Sep 17, 2025 at 5:14 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Sep 17, 2025 at 4:24 PM Hayato Kuroda (Fujitsu) > <kuroda.hayato@fujitsu.com> wrote: > > > > Dear Shlok, > > > > Thanks for creating the patch. Personally I prefer approach2; approach1 cannot > > indicate the current status of synchronization, it just shows the history. > > I feel approach2 has more information than approach1. > > > > I also think so but Ashutosh thought that it would be hacky. Ashutosh, > did you have an opinion on this matter after seeing the patches? > Yes, I’ve looked into both the patches. Approach 1 seems quite straightforward. In approach 2, we need to pass some additional arguments to update_local_sync_slot and update_and_persist_local_synced_slot, which makes it feel a little less clean compared to approach 1, where we simply add a new function and call it directly. That said, this is just my view on code cleanliness, I’m fine with proceeding with approach 2 if that’s considered the better option. -- With Regards, Ashutosh Sharma,
В списке pgsql-hackers по дате отправления: