Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns

Masahiko Sawada <sawada.mshk@gmail.com>

From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "Drouvot, Bertrand" <bdrouvot@amazon.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Oh, Mike" <minsoo@amazon.com>
Date: 2022-07-28T07:26:19Z
Lists: pgsql-hackers
On Thu, Jul 28, 2022 at 4:13 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Jul 28, 2022 at 11:56 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Thu, Jul 28, 2022 at 12:21 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Thu, Jul 28, 2022 at 7:18 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > >
> >
> > While editing back branch patches, I realized that the following
> > (parsed->xinfo & XACT_XINFO_HAS_INVALS) and (parsed->nmsgs > 0) are
> > equivalent:
> >
> > +   /*
> > +    * If the COMMIT record has invalidation messages, it could have catalog
> > +    * changes. It is possible that we didn't mark this transaction as
> > +    * containing catalog changes when the decoding starts from a commit
> > +    * record without decoding the transaction's other changes. So, we ensure
> > +    * to mark such transactions as containing catalog change.
> > +    *
> > +    * This must be done before SnapBuildCommitTxn() so that we can include
> > +    * these transactions in the historic snapshot.
> > +    */
> > +   if (parsed->xinfo & XACT_XINFO_HAS_INVALS)
> > +       SnapBuildXidSetCatalogChanges(ctx->snapshot_builder, xid,
> > +                                     parsed->nsubxacts, parsed->subxacts,
> > +                                     buf->origptr);
> > +
> >     /*
> >      * Process invalidation messages, even if we're not interested in the
> >      * transaction's contents, since the various caches need to always be
> >      * consistent.
> >      */
> >     if (parsed->nmsgs > 0)
> >     {
> >         if (!ctx->fast_forward)
> >             ReorderBufferAddInvalidations(ctx->reorder, xid, buf->origptr,
> >                                           parsed->nmsgs, parsed->msgs);
> >         ReorderBufferXidSetCatalogChanges(ctx->reorder, xid, buf->origptr);
> >     }
> >
> > If that's right, I think we can merge these if branches. We can call
> > ReorderBufferXidSetCatalogChanges() for top-txn and in
> > SnapBuildXidSetCatalogChanges() we mark its subtransactions if top-txn
> > is in the list. What do you think?
> >
>
> Note that this code doesn't exist in 14 and 15, so we need to create
> different patches for those.

Right.

> BTW, how in 13 and lower versions did we
> identify and mark subxacts as having catalog changes without our
> patch?

I think we use HEAP_INPLACE and XLOG_HEAP2_NEW_CID to mark subxacts as well.

Regards,

-- 
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



Commits

  1. Fix the incorrect assertion introduced in commit 7f13ac8123.

  2. Fix catalog lookup with the wrong snapshot during logical decoding.

  3. Clean up assorted failures under clang's -fsanitize=undefined checks.