Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary

On Tue, Feb 4, 2025 at 12:59 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Sun, Feb 2, 2025 at 8:11 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Jan 24, 2025 at 4:05 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > > When a standby replays a XLOG_PARAMETER_CHANGE record that lowers
> > > wal_level from logical, we invalidate all logical slots only when the
> > > standby is in hot standby mode:
> > >
> > > if (InRecovery && InHotStandby &&
> > >     xlrec.wal_level < WAL_LEVEL_LOGICAL &&
> > >     wal_level >= WAL_LEVEL_LOGICAL)
> > >     InvalidateObsoleteReplicationSlots(RS_INVAL_WAL_LEVEL,
> > >                                        0, InvalidOid,
> > >                                        InvalidTransactionId);
> > >
> > > However, it's possible that this record is replayed when not in hot
> > > standby mode and the slot is used after the promotion. In this case,
> > > the following Assert in xlog_decode() fails:
> > >
> > > /*
> > >  * This can occur only on a standby, as a primary would
> > >  * not allow to restart after changing wal_level < logical
> > >  * if there is pre-existing logical slot.
> > >  */
> >
> > Shouldn't we do similar to what this comment indicates on standby? We
> > can disallow to start the server as standby, if the hot_standby is off
> > and there is a pre-existing logical slot.
>
> It seems like a better idea. I thought we could pass StandbyMode to
> StartupReplicationSlots() and check if there is a pre-existing logical
> slot, but it would break the ABI compatibility. It might not be a
> problem in practice as StartupReplicationSlots() is normally used only
> by the startup process. But if we want to avoid that we can introduce
> a new function for that.

Since StandbyMode is exposed, we don't need to change the function
signature. I'll update and submit the patch soon.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com