Re: Unexpected Standby Shutdown on sync_replication_slots change

Le ven. 25 juil. 2025 à 12:32, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> a écrit :

> On Fri, Jul 25, 2025 at 6:40 PM Hugo DUBOIS <hdubois(at)scaleway(dot)com> wrote:
> >
> > Thanks for the quick patch. I've tested it on the REL_17_STABLE branch,
> and it's working fine.
> >
> > On a standby node, after dynamically setting the sync_replication_slots
> parameter, I observed the following logs. The instance did not shut down,
> which seems correct:
> >
> > 2025-07-25 09:26:34.613 UTC [4420] LOG: received SIGHUP, reloading
> configuration files
> > 2025-07-25 09:26:34.614 UTC [4420] LOG: parameter
> "sync_replication_slots" changed to "on"
> > 2025-07-25 09:26:34.615 UTC [4420] LOG: replication slot
> synchronization requires "wal_level" >= "logical"
> > 2025-07-25 09:27:34.662 UTC [4420] LOG: replication slot
> synchronization requires "wal_level" >= "logical"
> >
> > The instance did not restart as expected, showing this fatal log:
> >
> > 2025-07-25 09:27:45.668 UTC [4430] FATAL: replication slot
> synchronization ("sync_replication_slots" = on) requires "wal_level" >=
> "logical"
>
> Thanks for testing!
>
>
> > I have a couple of observations:
> >
> > With this patch, a primary instance will not restart if the
> configuration is incorrect.
>
> Right. In HEAD, the server shuts down due to the misconfiguration only when
> starting up as a standby and entering hot standby mode. With this patch,
> the server shuts down earlier—during startup—even when starting as a
> primary.
> If starting as a standby, the shutdown now happens before entering hot
> standby.
>
> It seems hard to match the current behavior exactly in the patch, and I’m
> not
> sure it’s worth trying. I think we have two options:
>
> #1. Make the server always shut down on misconfiguration, regardless of
> whether it starts as a primary or standby, and before reaching hot
> standby.
>
> #2. Allow the server to start even if the configuration is invalid.
>
> The current patch follows option #1. But if there are valid use cases for
> starting a primary with sync_replication_slots enabled and wal_level not
> set
> to logical, then option #2 might be better. What do you think?

I'm not sure if there's a particular use case for wal_level and
sync_replication_slots not matching on a primary. So, for me, Option 1
seems correct.

>

> Only wal_level is checked, but the ValidateSlotSyncParams function
> includes other mandatory parameters. These are not being checked during
> startup.
>
> The other parameters checked by ValidateSlotSyncParams() can be changed
> without restarting the server, so users can fix them on the fly while
> the server is running with the misconfiguration. But wal_level requires
> a server restart, so it's important to catch that upfront.
>

Ok.

> Regards,
>
> --
> Fujii Masao
>