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>
 <CAD21AoB4B3MOxJ7-v9YLjV5fTOtaLRUhX3jN3kqhEi7D7-uY4A@mail.gmail.com>
 <0c28fbd1-3320-4e9b-815c-6d62753aa063@wi3ck.info>
 <CAD21AoCmHpKrNg9D3mcOA973CZ5N_dBLxb8pERpSxEeRLSQxpA@mail.gmail.com>
 <CAD21AoAEVyxwn_bMWHvcU-Gcz3aUVjAtMbdgfoJ8MZNiLLEh0g@mail.gmail.com>
 <CAA4eK1Jkouj=w+PHzMB6v890ES3QOLf=cUTvZmGFr-WMQW2OnA@mail.gmail.com>
 <CAD21AoB4_n7+s=uM9apX1JVtvGvgM8ismAx_uMxvDmUXfQULsw@mail.gmail.com>
 <CAD21AoBJcxRcaWQot302diaxoDcsnezRhnZa7p8UrPh5AGNeHQ@mail.gmail.com>
 <CAA4eK1+ATysKLptbK+x8ygB7OAa=LHw3XTqMxKjVMsTRfdbRzQ@mail.gmail.com>
 <CAD21AoCLodVegaB=HDfxFMe8s9TMUxj+okznt6yjizN+5TVOfA@mail.gmail.com>
 <OS9PR01MB1214992889432F8A936AAAA32F557A@OS9PR01MB12149.jpnprd01.prod.outlook.com>
In-Reply-To: 
 <OS9PR01MB1214992889432F8A936AAAA32F557A@OS9PR01MB12149.jpnprd01.prod.outlook.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Fri, 27 Mar 2026 09:21:38 +0530
Message-ID: 
 <CAA4eK1LR4GaoqD_pt-KZrroCTaQZ3HCT3BiU1qGTRQLWpNRHmg@mail.gmail.com>
Subject: Re: Initial COPY of Logical Replication is too slow
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Jan Wieck <jan@wi3ck.info>,
	"pgsql-hackers@lists.postgresql.org" <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/CAA4eK1LR4GaoqD_pt-KZrroCTaQZ3HCT3BiU1qGTRQLWpNRHmg%40mail.gmail.com>
Precedence: bulk

On Fri, Mar 27, 2026 at 8:46=E2=80=AFAM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Sawada-san,
>
> > When passing a non-existent publication name, the current behavior
> > raises an error while the new behavior does nothing (i.e., the
> > difference is calling GetPublicationByName() with missing_ok =3D true o=
r
> > false).
>
> To confirm; It's because in PG18-, p.pubname was chosen from the pg_publi=
cation
> in the publisher, but this patch the name list is taken from the subscrib=
er, right?
> If some publications are dropped on the publisher, the ERROR could be rai=
sed.
>
> For the backward compatibility I suggest switching the policy based on th=
e API
> version. E.g.,
>
> ```
>  static Datum
>  pg_get_publication_tables(FunctionCallInfo fcinfo, ArrayType *pubnames,
> -                                                 Oid target_relid)
> +                                                 Oid target_relid, bool =
missing_ok)
> ...
> @@ -1631,7 +1631,7 @@ Datum
>  pg_get_publication_tables_a(PG_FUNCTION_ARGS)
>  {
>         /* Get the information of the tables in the given publications */
> -       return pg_get_publication_tables(fcinfo, PG_GETARG_ARRAYTYPE_P(0)=
, InvalidOid);
> +       return pg_get_publication_tables(fcinfo, PG_GETARG_ARRAYTYPE_P(0)=
, InvalidOid, false);
> ```
>

Sounds like a good idea for backward compatibility.

--=20
With Regards,
Amit Kapila.