Re: Add an option to skip loading missing publication to avoid logical replication failure - Mailing list pgsql-hackers

From vignesh C
Subject Re: Add an option to skip loading missing publication to avoid logical replication failure
Date
Msg-id CALDaNm0u53muOybA2Ncf1cDiqA4JJafB+7o3RwL13DgnBZKHVA@mail.gmail.com
Whole thread Raw
In response to Add an option to skip loading missing publication to avoid logical replication failure  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Mon, 19 Feb 2024 at 12:48, vignesh C <vignesh21@gmail.com> wrote:
>
> Hi,
>
> Currently ALTER SUBSCRIPTION ... SET PUBLICATION will break the
> logical replication in certain cases. This can happen as the apply
> worker will get restarted after SET PUBLICATION, the apply worker will
> use the existing slot and replication origin corresponding to the
> subscription. Now, it is possible that before restart the origin has
> not been updated and the WAL start location points to a location prior
> to where PUBLICATION pub exists which can lead to such an error. Once
> this error occurs, apply worker will never be able to proceed and will
> always return the same error.
>
> There was discussion on this and Amit had posted a patch to handle
> this at [2]. Amit's patch does continue using a historic snapshot but
> ignores publications that are not found for the purpose of computing
> RelSyncEntry attributes. We won't mark such an entry as valid till all
> the publications are loaded without anything missing. This means we
> won't publish operations on tables corresponding to that publication
> till we found such a publication and that seems okay.
> I have added an option skip_not_exist_publication to enable this
> operation only when skip_not_exist_publication is specified as true.
> There is no change in default behavior when skip_not_exist_publication
> is specified as false.

I have updated the patch to now include changes for pg_dump, added few
tests, describe changes and added documentation changes. The attached
v2 version patch has the changes for the same.

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: table inheritance versus column compression and storage settings
Next
From: Tom Lane
Date:
Subject: Re: numeric_big in make check?