Re: Unexpected Standby Shutdown on sync_replication_slots change

On Mon, Jul 28, 2025 at 10:18 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Fri, Jul 25, 2025 at 9:31 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> >
> > On Fri, Jul 25, 2025 at 9:13 PM Hugo DUBOIS <hdubois(at)scaleway(dot)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.
>

+1.

--
With Regards,
Amit Kapila.