RE: BUG #18267: Logical replication bug: data is not synchronized after Alter Publication. - Mailing list pgsql-bugs

From Hayato Kuroda (Fujitsu)
Subject RE: BUG #18267: Logical replication bug: data is not synchronized after Alter Publication.
Date
Msg-id TY3PR01MB9889E2912FFC40F5418EFF30F56A2@TY3PR01MB9889.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: BUG #18267: Logical replication bug: data is not synchronized after Alter Publication.  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-bugs
Dear Dilip,

> > > The root cause of the problem is as follows:
> > > pgoutput relies on the invalidation mechanism to validate publications. When
> > > walsender decoding an Alter Publication transaction, catalog caches are
> > > invalidated at once. Furthermore, since pg_publication_rel is modified,
> > > snapshot changes are added to all transactions currently being decoded. For
> > > other transactions, catalog caches have been invalidated. However, it is
> > > likely that the snapshot changes have not yet been decoded. In pgoutput
> > > implementation, these transactions query the system table pg_publication_rel
> > > to determine whether to publish changes made in transactions. In this case,
> > > catalog tuples are not found because snapshot has not been updated. As a
> > > result, changes in transactions are considered not to be published, and
> > > subsequent data cannot be synchronized.
> > >
> > > I think it's necessary to add invalidations to other transactions after
> > > adding a snapshot change to them.
> > > Therefore, I submitted a patch for this bug.
> >
> > I cannot see your attaching, but I found that proposed patch in [1] can solve
> > the issue. After applying 0001 + 0002 + 0003 (open relations as
> ShareRowExclusiveLock,
> > in OpenTableList), the data gap was removed. Thought?
> 
> Not sure why 'open relations as ShareRowExclusiveLock' would help in
> this case? have you investigated that?
>

Sorry for confusing, I did not analyze because I thought Song will tell us the
reason with his patch. I have just reported my tested... I will spend time later
based on the requirement.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

pgsql-bugs by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Wrong datatype in docs for wal_summary_keep_time
Next
From: Andres Freund
Date:
Subject: Re: BUG #18259: Assertion in ExtendBufferedRelLocal() fails after no-space-left condition