From: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: How can end users know the cause of LR slot sync delays? |
Date: | 2025-09-17 14:49:05 |
Message-ID: | CAE9k0P=FT6FrrjTg=wppvCCN21xmOxzGB1biJ37-+b=d+uE0-A@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Amit,
On Wed, Sep 17, 2025 at 5:14 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Sep 17, 2025 at 4:24 PM Hayato Kuroda (Fujitsu)
> <kuroda(dot)hayato(at)fujitsu(dot)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,
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2025-09-17 14:50:34 | Re: Schedule for PG 18 RC and GA releases |
Previous Message | Tom Lane | 2025-09-17 14:22:22 | Re: REPACK and naming |