On Tue, Mar 10, 2026 at 3:40 AM Masahiko Sawada <[email protected]> wrote: > > On Tue, Mar 3, 2026 at 2:22 AM Zhijie Hou (Fujitsu) > <[email protected]> wrote: > > > > On Saturday, February 28, 2026 7:48 AM Masahiko Sawada > > <[email protected]> wrote: > > > To: Marcos Pegoraro <[email protected]> > > > Cc: PostgreSQL Hackers <[email protected]> > > > 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. -- With Regards, Amit Kapila.
