Re: Initial COPY of Logical Replication is too slow - Mailing list pgsql-hackers

On Wed, Mar 18, 2026 at 3:31 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Mar 18, 2026 at 1:11 PM Jan Wieck <jan@wi3ck.info> wrote:
> >
> > On 3/18/26 12:44, Masahiko Sawada wrote:
> > > On Wed, Mar 18, 2026 at 6:56 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >>
> > >> On Tue, Mar 10, 2026 at 3:40 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >> >
> > >> > On Tue, Mar 3, 2026 at 2:22 AM Zhijie Hou (Fujitsu)
> > >> > <houzj.fnst@fujitsu.com> wrote:
> > >> > >
> > >> > > On Saturday, February 28, 2026 7:48 AM Masahiko Sawada <sawada.mshk@gmail.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 patch changes
> > >> > > > its signature to {text[] [, oid]}, breaking the tool compatibility. Given this
> > >> > > > function is mostly an internal-use function (we don't have the documentation
> > >> > > > for it), it would probably be okay with it. I find it's clearer than the other
> > >> > > > approach of introducing pg_get_publication_table_info(). Feedback is 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 the
> > >> > > publisher version is newer and the subscriber version is older ? E.g., when
> > >> > > publisher is passing text style publication name to pg_get_publication_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.
> >
> > Would it be possible to use function overloading to provide both
> > signatures handled by different C functions internally?
>
> Yes, we can define both pg_get_publication_tables(VARIADIC text[]) and
> pg_get_publication_tables(text, oid), which seems like a less invasive
> approach. I'll give this idea a shot and see how it goes.

I've attached the patch to implement this idea. The patch still
introduces a new function but it overloads
pg_get_publication_tables(). We might be able to handle different
input (array or text) in pg_get_publication_tables() better, but it's
enough for discussion at least.

Regards,

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