> On Jan 30, 2026, at 23:28, Fujii Masao <[email protected]> wrote:
>
> On Fri, Jan 30, 2026 at 4:49 PM Chao Li <[email protected]> wrote:
>>
>>
>>
>>> On Jan 30, 2026, at 14:59, Shinya Kato <[email protected]> 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/[email protected]
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
