Horton

Thread

Commits

  1. Release synchronous replication waiters immediately on configuration changes.

  1. Wake up backends immediately when sync standbys decrease

    Shinya Kato <shinya11.kato@gmail.com> — 2026-01-30T06:59:42Z

    Hi hackers,

I have noticed an issue where backends waiting for synchronous
replication are not woken up immediately when the number of required
synchronous standbys is reduced in a multiple synchronous standby
environment.

When synchronous_standby_names is updated to require fewer standbys
(for example, changing from "FIRST 2 (s1, s2)" to "FIRST 1 (s1)"), the
backends currently waiting for replication remain blocked even after a
config reload (SIGHUP). They are only released when a new message
eventually arrives from a standby, despite the fact that the new
requirements are already satisfied.

The attached patch adds SyncRepReleaseWaiters() calls within
walsender.c immediately after the configuration is reloaded and
SyncRepInitConfig() is called. This ensures that any backends whose
waiting conditions are now met by the new configuration are released
without unnecessary delay.

Thoughts?

-- 
Best regards,
Shinya Kato
NTT OSS Center

  2. Re: Wake up backends immediately when sync standbys decrease

    Chao Li <li.evan.chao@gmail.com> — 2026-01-30T07:49:16Z

    
> On Jan 30, 2026, at 14:59, Shinya Kato <shinya11.kato@gmail.com> wrote:
> 
> Hi hackers,
> 
> I have noticed an issue where backends waiting for synchronous
> replication are not woken up immediately when the number of required
> synchronous standbys is reduced in a multiple synchronous standby
> environment.
> 
> When synchronous_standby_names is updated to require fewer standbys
> (for example, changing from "FIRST 2 (s1, s2)" to "FIRST 1 (s1)"), the
> backends currently waiting for replication remain blocked even after a
> config reload (SIGHUP). They are only released when a new message
> eventually arrives from a standby, despite the fact that the new
> requirements are already satisfied.
> 
> The attached patch adds SyncRepReleaseWaiters() calls within
> walsender.c immediately after the configuration is reloaded and
> SyncRepInitConfig() is called. This ensures that any backends whose
> waiting conditions are now met by the new configuration are released
> without unnecessary delay.
> 
> Thoughts?
> 
> -- 
> Best regards,
> Shinya Kato
> NTT OSS Center
> <v1-0001-Wake-up-backends-immediately-when-sync-standbys-d.patch>

Hi Shinya-san,

This patch makes sense to me, and the behavior change looks reasonable.

My main concern is code duplication. The same block is added in three places. While the existing reload handling is already 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:

```
static void
WalSndHandleConfigReload(void)
{
    if (!ConfigReloadPending)
        return;

    ConfigReloadPending = false;
    ProcessConfigFile(PGC_SIGHUP);
    SyncRepInitConfig();

    if (!am_cascading_walsender)
        SyncRepReleaseWaiters();
}
```

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

  3. Re: Wake up backends immediately when sync standbys decrease

    Fujii Masao <masao.fujii@gmail.com> — 2026-01-30T15:28:14Z

    On Fri, Jan 30, 2026 at 4:49 PM Chao Li <li.evan.chao@gmail.com> wrote:
>
>
>
> > On Jan 30, 2026, at 14:59, Shinya Kato <shinya11.kato@gmail.com> wrote:
> >
> > Hi hackers,
> >
> > I have noticed an issue where backends waiting for synchronous
> > replication are not woken up immediately when the number of required
> > synchronous standbys is reduced in a multiple synchronous standby
> > environment.

Thanks for reporting this!

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?


> My main concern is code duplication. The same block is added in three places. While the existing reload handling is already 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

Regards,


-- 
Fujii Masao

  4. Re: Wake up backends immediately when sync standbys decrease

    Shinya Kato <shinya11.kato@gmail.com> — 2026-02-01T06:24:45Z

    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 is already 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.


-- 
Best regards,
Shinya Kato
NTT OSS Center

  5. Re: Wake up backends immediately when sync standbys decrease

    Chao Li <li.evan.chao@gmail.com> — 2026-02-01T22:44:29Z

    
> On Feb 1, 2026, at 14:24, 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 is already 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.
> 
> 
> -- 
> Best regards,
> Shinya Kato
> NTT OSS Center
> <v2-0001-Wake-up-backends-immediately-when-synchronous_sta.patch>

Thanks for updating the patch. V2 LGTM.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

  6. Re: Wake up backends immediately when sync standbys decrease

    Xuneng Zhou <xunengzhou@gmail.com> — 2026-02-02T02:28:05Z

    Hi Kato-san,

Thanks for working on this.

On Sun, Feb 1, 2026 at 2: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 is already 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.
>
>
> --
> Best regards,
> Shinya Kato
> NTT OSS Center

v2 LGTM.

-- 
Best,
Xuneng

  7. Re: Wake up backends immediately when sync standbys decrease

    Chao Li <li.evan.chao@gmail.com> — 2026-02-02T06:29:20Z

    
> On Jan 30, 2026, at 23:28, Fujii Masao <masao.fujii@gmail.com> wrote:
> 
> On Fri, Jan 30, 2026 at 4:49 PM Chao Li <li.evan.chao@gmail.com> wrote:
>> 
>> 
>> 
>>> On Jan 30, 2026, at 14:59, Shinya Kato <shinya11.kato@gmail.com> wrote:
>>> 
>>> Hi hackers,
>>> 
>>> I have noticed an issue where backends waiting for synchronous
>>> replication are not woken up immediately when the number of required
>>> synchronous standbys is reduced in a multiple synchronous standby
>>> environment.
> 
> Thanks for reporting this!
> 
> 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?
> 
> 
>> My main concern is code duplication. The same block is added in three places. While the existing reload handling is already 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
> 
> Regards,
> 
> 
> -- 
> Fujii Masao

Hi Fujii-san,

While reviewing this patch, I noticed a small issue where MyReplicationSlot is dereferenced without checking whether it is NULL. I’ve posted a small follow-up patch to address this. Could you please take a look at [1] when you have a chance?

[1] https://postgr.es/m/6E7BD4F7-C22A-4B6C-A9BD-62877390DF86@gmail.com

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

  8. Re: Wake up backends immediately when sync standbys decrease

    Fujii Masao <masao.fujii@gmail.com> — 2026-02-02T16:03:49Z

    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 is already 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

  9. Re: Wake up backends immediately when sync standbys decrease

    Shinya Kato <shinya11.kato@gmail.com> — 2026-02-03T00:43:25Z

    On Tue, Feb 3, 2026 at 1:04 AM Fujii Masao <masao.fujii@gmail.com> wrote:

> > 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.

Thank you very much!

>
> 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.

Okay, I've got it.


-- 
Best regards,
Shinya Kato
NTT OSS Center

  10. Re: Wake up backends immediately when sync standbys decrease

    Fujii Masao <masao.fujii@gmail.com> — 2026-02-03T02:16:00Z

    On Tue, Feb 3, 2026 at 9:44 AM Shinya Kato <shinya11.kato@gmail.com> wrote:
>
> On Tue, Feb 3, 2026 at 1:04 AM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> > > 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.
>
> Thank you very much!
>
> >
> > 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.
>
> Okay, I've got it.

I've pushed the patch. Thanks!

Regards,


-- 
Fujii Masao