Re: Unexpected Standby Shutdown on sync_replication_slots change - Mailing list pgsql-bugs

On Fri, Jul 25, 2025 at 9:31 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Fri, Jul 25, 2025 at 9:13 PM Hugo DUBOIS <hdubois@scaleway.com> wrote:
> > 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. 
>
> I also prefer option #1.
>
> However, on second thought, if some users are already running a server
> (non-standby) with sync_replication_slots enabled and wal_level != logical
> in v17, switching to option #1 could break their setup after a minor
> version update. That would be surprising and confusing.
>
> To avoid that, I think we should go with option #2—at least for v17.
>

I still prefer option #1. On HEAD, option #1 makes sense because
wal_level is a GUC that requires a server restart and thus using
ERROR/FATAL in this context is appropriate. It is also consistent with
the rest of the code (other modules) wherever wal_level checks are
performed during startup.

Regarding the back branches, in the case of a primary server, if
sync_replication_slots is left ON while wal_level < logical, then
issuing a ERROR/FATAL is still more suitable. The user can simply
correct the configuration (disable sync_replication_slots) and proceed
with the startup after the minor version upgrade. Also, given that
option #1 is the better fit for HEAD, I don't think it's worth having
different behavior in the back branches. Thoughts?

thanks
Shveta