Re: Dropping publication breaks logical replication - Mailing list pgsql-hackers

From vignesh C
Subject Re: Dropping publication breaks logical replication
Date
Msg-id CALDaNm3vj1zUi6-8x2jaMs9LYu+DwTu=PKPunLfSbRDAWspvXQ@mail.gmail.com
Whole thread Raw
In response to Re: Dropping publication breaks logical replication  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Dropping publication breaks logical replication
Re: Dropping publication breaks logical replication
List pgsql-hackers
On Mon, 4 Aug 2025 at 09:47, Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Hi Vignesh,
> Thanks for the patches.
>
> On Sat, Aug 2, 2025 at 7:10 PM vignesh C <vignesh21@gmail.com> wrote:
>
> > >
> > > The backport seems to be straight forward. Please let me know if you
> > > need my help in doing so, if we decide to backport the fix.
> >
> > Now that this has been reported on the back branches, we should
> > consider whether it's appropriate to backport the fix. Here are the
> > patches prepared for the back branches.
>
> PG14 and + patches do not test that DROP PUBLICATION does not disrupt
> the publication. I think we need to test that as well.

Currently, the test across all branches except PG13 is the same test
used in the master branch. For PG13, since there was no existing
subscription, I modified the test slightly to accommodate that. If I
handle the comment you suggest, the test in master and the backbranch
will be different. Should we keep the test similar to the master or is
it ok to address your above comment and keep it different?

> PG13 tests DROP PUBLICATION OTOH. That's good. I think it has a race
> condition because +my $offset = -s $node_publisher->logfile; is
> executed after dropping the publication. If some background change
> triggers publication validation before capturing the file offset, we
> might miss the WARNING and the test will fail. Instead capturing
> offset before dropping publication may be safer - the publication
> exists till it dropped, so the log file cannot have WARNING in there
> when offset is captured.

I will handle this in the next version.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: GB18030-2022 Support in PostgreSQL
Next
From: shveta malik
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart