Re: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Skipping logical replication transactions on subscriber side
Date
Msg-id CAD21AoDb07XhDmJLnYzEfoM8LEbYG=FjtsDJjG7YXVNRA-Po+Q@mail.gmail.com
Whole thread Raw
In response to Re: Skipping logical replication transactions on subscriber side  (Noah Misch <noah@leadboat.com>)
Responses Re: Skipping logical replication transactions on subscriber side
List pgsql-hackers
On Mon, Apr 4, 2022 at 3:26 PM Noah Misch <noah@leadboat.com> wrote:
>
> On Mon, Apr 04, 2022 at 08:20:08AM +0530, Amit Kapila wrote:
> > On Mon, Apr 4, 2022 at 8:01 AM Noah Misch <noah@leadboat.com> wrote:
> > > On Mon, Apr 04, 2022 at 10:28:30AM +0900, Masahiko Sawada wrote:
> > > > On Sun, Apr 3, 2022 at 9:45 AM Noah Misch <noah@leadboat.com> wrote:
> > > > > On Sat, Apr 02, 2022 at 08:44:45PM +0900, Masahiko Sawada wrote:
> > > > > > On Sat, Apr 2, 2022 at 7:04 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > > > > > On Sat, Apr 2, 2022 at 1:43 PM Noah Misch <noah@leadboat.com> wrote:
> > > > > > > > Some options:
> > > > > > > > - Move subskiplsn after subdbid, so it's always aligned anyway.  I've
> > > > > > > >   confirmed that this lets the test pass, in 44s.
> > >
> > > > --- a/src/include/catalog/pg_subscription.h
> > > > +++ b/src/include/catalog/pg_subscription.h
> > > > @@ -54,6 +54,17 @@ CATALOG(pg_subscription,6100,SubscriptionRelationId) BKI_SHARED_RELATION BKI_ROW
> > > >
> > > >       Oid                     subdbid BKI_LOOKUP(pg_database);        /* Database the
> > > >                                                                                                        *
subscriptionis in. */
 
> > > > +
> > > > +     /*
> > > > +      * All changes finished at this LSN are skipped.
> > > > +      *
> > > > +      * Note that XLogRecPtr, pg_lsn in the catalog, is 8-byte alignment
> > > > +      * (TYPALIGN_DOUBLE) and it does not match the alignment on some platforms
> > > > +      * such as AIX.  Therefore subskiplsn needs to be placed here so it is
> > > > +      * always aligned.
> > >
> > > I'm reading this comment as saying that TYPALIGN_DOUBLE is always 8 bytes, but
> > > the problem arises precisely because TYPALIGN_DOUBLE==4 on AIX.
> >
> > How about a comment like: "It has to be kept at 8-byte alignment
> > boundary so as to be accessed directly via C struct as it uses
> > TYPALIGN_DOUBLE for storage which has 4-byte alignment on platforms
> > like AIX."? Can you please suggest a better comment if you don't like
> > this one?
>
> I'd write it like this, though I'm not sure it's an improvement on your words:
>
>   When ALIGNOF_DOUBLE==4 (e.g. AIX), the C ABI may impose 8-byte alignment on
>   some of the C types that correspond to TYPALIGN_DOUBLE SQL types.  To ensure
>   catalog C struct layout matches catalog tuple layout, arrange for the tuple
>   offset of each fixed-width, attalign='d' catalog column to be divisible by 8
>   unconditionally.  Keep such columns before the first NameData column of the
>   catalog, since packagers can override NAMEDATALEN to an odd number.

Thanks!

>
> The best place for such a comment would be in one of
> src/test/regress/sql/*sanity*.sql, next to a test written to detect new
> violations.

Agreed.

IIUC in the new test, we would need a new SQL function to calculate
the offset of catalog columns including padding, is that right? Or do
you have an idea to do that by using existing functionality?

Regards,

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



pgsql-hackers by date:

Previous
From: "Andrey V. Lepikhov"
Date:
Subject: Re: Defer selection of asynchronous subplans until the executor initialization stage
Next
From: Dilip Kumar
Date:
Subject: Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints