Re: Skipping logical replication transactions on subscriber side

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Alexey Lesovsky <lesovsky(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Skipping logical replication transactions on subscriber side
Date: 2022-04-06 08:53:28
Message-ID: 31b9125f-9904-25fb-c085-973facade0f4@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 02.04.22 10:13, Noah Misch wrote:
> uint64 and pg_lsn use TYPALIGN_DOUBLE. For AIX, they really need a typalign
> corresponding to ALIGNOF_LONG. Hence, the C struct layout doesn't match the
> tuple layout. Columns potentially affected:
>
> [local] test=*# select attrelid::regclass, attname from pg_attribute a join pg_class c on c.oid = attrelid where attalign = 'd' and relkind = 'r' and attnotnull and attlen <> -1;
> attrelid │ attname
> ─────────────────┼──────────────
> pg_sequence │ seqstart
> pg_sequence │ seqincrement
> pg_sequence │ seqmax
> pg_sequence │ seqmin
> pg_sequence │ seqcache
> pg_subscription │ subskiplsn
> (6 rows)
>
> The pg_sequence fields evade trouble, because there's exactly eight bytes (two
> oids) before them.

Yes, we carefully did this when we ran into this the last time. See
<https://www.postgresql.org/message-id/flat/76ce2ca3-40f2-d291-eae2-17b599f29ba0%402ndquadrant.com#cf1313adff98e1d5e1ca789497898310>
and commit f3b421da5f4addc95812b9db05a24972b8fd9739.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-04-06 09:11:04 Re: shared-memory based stats collector - v70
Previous Message Bharath Rupireddy 2022-04-06 08:45:12 Re: pg_walinspect - a new extension to get raw WAL data and WAL stats