On Fri, Jul 25, 2025 at 6:40 PM Hugo DUBOIS <hdubois@scaleway.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.
