Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary - Mailing list pgsql-hackers

Hi,

On Mon, Feb 24, 2025 at 05:01:30PM +0530, Amit Kapila wrote:
> On Wed, Feb 12, 2025 at 5:22 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Wed, Feb 12, 2025 at 1:16 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > >
> > > Agreed, I'm fine with leaving InRecovery in this condition. I think
> > > the point is whether we should add StandbyMode to the condition or
> > > not. I think if we do that, we would end up with the same error in the
> > > above scenario I described. So does the following condition make
> > > sense?
> > >
> > >         if (InRecovery &&
> > >             xlrec.wal_level < WAL_LEVEL_LOGICAL &&
> > >             wal_level >= WAL_LEVEL_LOGICAL)
> > >             InvalidateObsoleteReplicationSlots(RS_INVAL_WAL_LEVEL,
> > >                                                0, InvalidOid,
> > >                                                InvalidTransactionId);
> > >
> >
> > This will still be true for crash-recovery as the InRecovery flag will
> > be true for that case as well. I think we should go with your v2 patch
> > approach for HEAD and back-branches.
> >
> 
> Any opinion on how to proceed here?

As far I'm concerned, I did not change my mind since [1] and think the same i.e:
go with v2 for HEAD and back-branches.

[1]: https://www.postgresql.org/message-id/Z6W7GtSzeDcZec%2Bf%40ip-10-97-1-34.eu-west-3.compute.internal

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com