Re: Wake up backends immediately when sync standbys decrease - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Wake up backends immediately when sync standbys decrease
Date
Msg-id CAHGQGwFauFYyxZy9+s89U+NRRPPw7V7fK2K_qGzWinJJG=Rhyw@mail.gmail.com
Whole thread Raw
In response to Re: Wake up backends immediately when sync standbys decrease  (Shinya Kato <shinya11.kato@gmail.com>)
Responses Re: Wake up backends immediately when sync standbys decrease
List pgsql-hackers
On Sun, Feb 1, 2026 at 3:25 PM Shinya Kato <shinya11.kato@gmail.com> wrote:
>
> Thank you for the reviews!
>
> On Sat, Jan 31, 2026 at 12:28 AM Fujii Masao <masao.fujii@gmail.com> wrote:
> > This issue can occur not only when the number of sync standbys is reduced,
> > but also when the configured standby names change. For example, if the config
> > changes from "FIRST 2 (sby1, sby2)" to "FIRST 2 (sby1, sby3)",
> > waiters on sby2 should be released immediately. But, currently, there can
> > a delay before that happens. Right?
>
> Yes, you're right, so I revised the comments and commit message.
>
> > > My main concern is code duplication. The same block is added in three places. While the existing reload handling
isalready duplicated there, adding more logic on top makes the situation a bit worse from a maintenance perspective. 
> > >
> > > Would it make sense to factor the reload handling into a small helper, for example:
> >
> > +1
>
> I've updated it in the v2 patch.

Thanks for updating the patch! It looks good to me.

I've run pgindent and updated the commit log slightly. The revised patch is
attached. I'll commit it.

As noted in the commit log of the latest patch, I think this an improvement
rather than a bug fix, so I plan to apply it only to the master branch.

Regards,

--
Fujii Masao

Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Is there value in having optimizer stats for joins/foreignkeys?
Next
From: Vitaly Davydov
Date:
Subject: Re: Support logical replication of DDLs