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

On Thu, Mar 26, 2026 at 8:51 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Mar 27, 2026 at 8:46 AM 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 = true or
> > > false).
> >
> > To confirm; It's because in PG18-, p.pubname was chosen from the pg_publication
> > in the publisher, but this patch the name list is taken from the subscriber, right?
> > If some publications are dropped on the publisher, the ERROR could be raised.
> >
> > For the backward compatibility I suggest switching the policy based on the 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.

+1.

I've attached the updated patch. I believe I've addressed all comments
I got so far. In addition to that, I've refactored
is_table_publishable_in_publication() and added more regression tests.

Regards,

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