Re: pg_createsubscriber does not check output_plugin_libraries - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: pg_createsubscriber does not check output_plugin_libraries
Date
Msg-id CAHGQGwH+0R_Qsekwh0kqEUhPwyGkcj1jPU7y5MLwGb8kqUELLA@mail.gmail.com
Whole thread
In response to RE: pg_createsubscriber does not check output_plugin_libraries  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
On Fri, Sep 4, 2026 at 8:47 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Fujii-san,
>
> Thanks for reviewing. I think your points are correct. PSA new version.
> Only needed patches were attached.

Thanks for updating the patches!

I found that output_plugin_libraries is PGC_SUSET, so its value may
differ between databases. But, with the patch, pg_createsubscriber
seems to check output_plugin_libraries only in the database specified by
conninfo, not in the databases specified by --database, where the
subscriptions are actually created.

If output_plugin_libraries does not include pgoutput in one of the
databases specified by --database, --dry-run could succeed, while the
actual run could fail because pgoutput is not allowed in that database.
Isn't this a problem?


-  # Note that src/bin/pg_upgrade/check.c assumes GUC_LIST_QUOTE here.
+  # Note that src/bin/pg_upgrade/check.c and
src/bin/pg_basebackup/pg_createsubscriber.c assume GUC_LIST_QUOTE
here.

For the v18 patch, should the corresponding comment also be updated in
src/backend/utils/misc/guc_tables.c?

    /* note: src/bin/pg_upgrade/check.c assumes GUC_LIST_QUOTE here */
    GUC_LIST_INPUT | GUC_LIST_QUOTE | GUC_SUPERUSER_ONLY


> IIUC the same issue could happen till PG18. Not sure the case when
> GUC was added to the old version, but I feel it could be backpatched.
> Patches for PG18 were also attached. For PG19, same ones as HEAD
> were usable.

What about v17? We should backpatch this to v17 as well, since both
output_plugin_libraries and pg_createsubscriber are supported there?

Regards,

--
Fujii Masao



pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: SUM(int2)/SUM(int4) do not detect overflow of the int8 accumulator
Next
From: Thom Brown
Date:
Subject: Re: REPACK (CONCURRENTLY) can crash a logical decoding session