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

From Amit Kapila
Subject Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary
Date
Msg-id CAA4eK1J6CtvsEV-fLPDa3P5yyRUX=RAnF--E+gYXc6VaC-KkbQ@mail.gmail.com
Whole thread Raw
In response to Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary
List pgsql-hackers
On Wed, Feb 5, 2025 at 2:06 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> I've attached the updated patch. The fix needs to be back-patched to
> v16 where logical decoding on standby was introduced.
>

Isn't it better to give the new ERROR near the below code?
RestoreSlotFromDisk()
{
...
if (cp.slotdata.database != InvalidOid && wal_level < WAL_LEVEL_LOGICAL)
ereport(FATAL,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("logical replication slot \"%s\" exists, but \"wal_level\" <
\"logical\"",
NameStr(cp.slotdata.name)),
...
}

If feasible, this will avoid an additional loop over the slots and a
new ERROR will be added at the same place as an existing similar
ERROR.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Conflict detection for update_deleted in logical replication
Next
From: vignesh C
Date:
Subject: Re: Restrict publishing of partitioned table with a foreign table as partition