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

From Jan Wieck
Subject Re: Initial COPY of Logical Replication is too slow
Date
Msg-id 0c28fbd1-3320-4e9b-815c-6d62753aa063@wi3ck.info
Whole thread Raw
In response to Re: Initial COPY of Logical Replication is too slow  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Initial COPY of Logical Replication is too slow
List pgsql-hackers
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?


Best Regards, Jan




pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Re: Adding REPACK [concurrently]
Next
From: Andres Freund
Date:
Subject: Re: Don't synchronously wait for already-in-progress IO in read stream