MIME-Version: 1.0
References: 
 <CAB-JLwbBFNuASyEnZWP0Tck9uNkthBZqi6WoXNevUT6+mV8XmA@mail.gmail.com>
 <CAD21AoA6i2ui8FMZeuU_KxX4t-fM8G==zTW2Dp6-goujttrpew@mail.gmail.com>
 <CAB-JLwZpp=7c9_r0beWWJxRh2BS_2Vvth8UDv7H57DBeaqggVg@mail.gmail.com>
 <CAD21AoDT3sL2COprsRumM9zEpL1Bk5VWboK4V2mRnjGua8xfeA@mail.gmail.com>
 <CAD21AoDQM62GOtaTzD_CVMSsFhv6o9c0Au1dSM1QuxeKFkWAKw@mail.gmail.com>
 <CAD21AoCz7HjEr3oeb=haK31YHxHZLcvD_wx_a-+xLPKywq++3A@mail.gmail.com>
 <TY4PR01MB16907733B75A99117F013AFCA947FA@TY4PR01MB16907.jpnprd01.prod.outlook.com>
 <CAD21AoA9YgiY1rVKMPZwB00WU_G4UfzoawY=7hyd7hpvBPcK6w@mail.gmail.com>
 <CAA4eK1KoSi60dtakJzn0MxNnHF1Yf4indSAffTjJxQG_31jsgQ@mail.gmail.com>
In-Reply-To: 
 <CAA4eK1KoSi60dtakJzn0MxNnHF1Yf4indSAffTjJxQG_31jsgQ@mail.gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Wed, 18 Mar 2026 09:44:46 -0700
Message-ID: 
 <CAD21AoB4B3MOxJ7-v9YLjV5fTOtaLRUhX3jN3kqhEi7D7-uY4A@mail.gmail.com>
Subject: Re: Initial COPY of Logical Replication is too slow
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>,
 Marcos Pegoraro <marcos@f10.com.br>,
	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/CAD21AoB4B3MOxJ7-v9YLjV5fTOtaLRUhX3jN3kqhEi7D7-uY4A%40mail.gmail.com>
Precedence: bulk

On Wed, Mar 18, 2026 at 6:56=E2=80=AFAM Amit Kapila <amit.kapila16@gmail.co=
m> wrote:
>
> On Tue, Mar 10, 2026 at 3:40=E2=80=AFAM Masahiko Sawada <sawada.mshk@gmai=
l.com> wrote:
> >
> > On Tue, Mar 3, 2026 at 2:22=E2=80=AFAM Zhijie Hou (Fujitsu)
> > <houzj.fnst@fujitsu.com> wrote:
> > >
> > > On Saturday, February 28, 2026 7:48 AM Masahiko Sawada <sawada.mshk@g=
mail.com> wrote:
> > > > To: Marcos Pegoraro <marcos@f10.com.br>
> > > > Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
> > > > Subject: Re: Initial COPY of Logical Replication is too slow
> > > >
> > > > Another variant of this approach is to extend
> > > > pg_get_publication_table() so that it can accept a relid to get the=
 publication
> > > > information of the specific table. I've attached the patch for this=
 idea. I'm
> > > > going to add regression test cases.
> > > >
> > > > pg_get_publication_table() is a VARIACID array function so the patc=
h changes
> > > > its signature to {text[] [, oid]}, breaking the tool compatibility.=
 Given this
> > > > function is mostly an internal-use function (we don't have the docu=
mentation
> > > > for it), it would probably be okay with it. I find it's clearer tha=
n the other
> > > > approach of introducing pg_get_publication_table_info(). Feedback i=
s very
> > > > welcome.
> > >
> > > Thanks for updating the patch.
> > >
> > > I have few comments for the function change:
> > >
> > > 1.
> > >
> > > If we change the function signature, will it affect use cases where t=
he
> > > publisher version is newer and the subscriber version is older ? E.g.=
, when
> > > publisher is passing text style publication name to pg_get_publicatio=
n_tables().
> >
> > Good point.
> >
> > I noticed that changing the function signature of
> > pg_get_publication_tables() breaks logical replication setups where
> > the subscriber is 18 or older.
> >
>
> Why adding a new function with additional parameters (Oid relid)
> couldn't help with such a case? I am asking because your previous
> version code looks simpler as compared to the new patch version.

I tried to pass a relid to pg_get_publication_tables() but we cannot
avoid changing its signature because it's a VARIADIC array function.
The previous patch changed pg_get_publication_tables(VARIADIC text[])
to pg_get_publication_tables(text[] {, relid}). However, changing the
function signature would break the logical replication from v19 to an
older version.

Regards,

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