MIME-Version: 1.0
References: <CAD21AoCzjzr5VqVkpVWkN7V6vrFhac=yXSNMz6rkSE+KOPPU0w@mail.gmail.com>
 <CAExHW5ufb1CAcEP1o03M3c=q6AgCzdSLOFaxbC-dJN-k7ymqaA@mail.gmail.com>
 <38690b0e-f91b-46fa-b72a-57775612e463@postgrespro.ru> <CAD21AoCTdgHGcEQLwbqXR1E6aC1VyO8wOB4S4U6nU50bZQ+NzQ@mail.gmail.com>
 <CAD21AoCzT3sytVbimRNdjRF=N3R-8ddaWKW95EzsdderXqcm4g@mail.gmail.com>
 <CAFiTN-t1d3vzTMy4X=R_9m2AOmyVKpYQWKfZnOrat2voBi-K9g@mail.gmail.com>
 <CAA4eK1LoUyyPGZExMRuhQ2g=_PvpE-NQra-dcE1OF=WeWnURZQ@mail.gmail.com>
 <CAMT0RQQQ5DAE74GSFnEAtEOGN3tXcXYt==fR1gPZ+PGZD+waPg@mail.gmail.com>
 <CAFiTN-vG4z03ar5PMYT3ehe+yzKH8+nPR4uqhNEhnax0DmOq_g@mail.gmail.com>
 <CAMT0RQThNce3+0MEzbqNWov7uZZQbiyFrhrod3g+MeKoAqjRbw@mail.gmail.com>
 <2oh4o4zvj2jreituesxgglmnseo2m2brffms3lvao6mseemto6@32v67ejhxlht> <CAMT0RQS-Tr9kuP6ChJaL7UjzY1gbtnAqOuPHZesKVpSkwHJiVw@mail.gmail.com>
In-Reply-To: <CAMT0RQS-Tr9kuP6ChJaL7UjzY1gbtnAqOuPHZesKVpSkwHJiVw@mail.gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Fri, 1 May 2026 11:40:33 -0700
Message-ID: <CAD21AoAg0UnVna7XmCo9a5HP=KZEPft4Ng5TB=cQ_BLawthSZw@mail.gmail.com>
Subject: Re: Support logical replication of DDLs, take2
To: Hannu Krosing <hannuk@google.com>
Cc: Andres Freund <andres@anarazel.de>, Dilip Kumar <dilipbalaut@gmail.com>, 
	Amit Kapila <amit.kapila16@gmail.com>, Vitaly Davydov <v.davydov@postgrespro.ru>, 
	Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAD21AoAg0UnVna7XmCo9a5HP%3DKZEPft4Ng5TB%3DcQ_BLawthSZw%40mail.gmail.com>
Precedence: bulk

On Thu, Apr 30, 2026 at 7:03=E2=80=AFAM Hannu Krosing <hannuk@google.com> w=
rote:
>
> On Wed, Apr 29, 2026 at 2:10=E2=80=AFPM Andres Freund <andres@anarazel.de=
> wrote:
> >
> > Hi,
> >
> > On 2026-04-29 10:07:04 +0200, Hannu Krosing wrote:
> > > On Wed, Apr 29, 2026 at 5:39=E2=80=AFAM Dilip Kumar <dilipbalaut@gmai=
l.com> wrote:
> > >
> > > > I am trying to understand your idea. If we are trying to deparse fr=
om
> > > > an actual system table using a snapshot, why don't we just use the
> > > > WAL? I mean, the WAL should contain the actual catalog modification=
s
> > > > it has made.
> > >
> > > We have the full data in the catalog and we would likely need catalog
> > > queries for any change, even when de-parsing the tree.
> > >
> > > And we should not add the extra load on the original DDL side, just a=
s
> > > we don't for DML.
> >
> > That can't be a relevant cost compared to everything else.
>
> Probably not. But unless we somehow encode "everything" at that point
> we will make building different DDL decoders harder down the line.
>
> So why not just save the normally serialised parse tree at this point
> and let the decoders decide to do whatever they need.
>
> > > At most we could just serialize the statement tree into the WAL,
> > > though even that may be an overkill if we can get the change from
> > > existing records.
> > >
> > > - insert new row in pg_class --> extract the CREATE TABLE (or INDEX, =
or ...)
> > > - update row in pg_class or insert, update or delete a row in
> > > pg_attribute --> extract ALTER TABLE
> > >   - except when it just updates relfilenod --> extract TRUNCATE
> > > - delete row in pg_class --> DROP TABLE
> > > - dml on pg_constraint --> ALTER TABLE
> > >
> > > ... etc
> >
> > That doesn't work in the general case, think of
> > ALTER TABLE ... ALTER COLUMN ... TYPE foo USING (...)
> >
> > There's a big difference between USING(foo::int8) and USING (pg_size_by=
tes(foo))
> > but it's nowhere visible in the WAL.
>
> It can't be a big difference if it is not visible in the WAL.

If we send the rewritten tuples made during ALTER TABLE execution via
logical replication, there would not be a big difference. However, if
we send only the re-constructed ALTER TABLE statement, there is. I
think that replicating ALTER TABLE should behave the latter because we
might not need table rewrites in more ALTER TABLE cases in newer
PostgreSQL versions.

Regards,

--=20
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com