> 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
alreadyduplicated 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
isNULL. 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/
