Re: pg_createsubscriber does not check output_plugin_libraries

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: pg_createsubscriber does not check output_plugin_libraries
Date: 2026-09-08 16:33:18
Message-ID: CAOYmi+=AoWyU=MqfsFWUP2QHxsydHG9w2VuNnzswoBZCsCOobg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 3, 2026 at 8:49 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Hi hackers,
> (CC: Jacob, who was an author of 226e49cb)

Hi! Thanks for the report, and sorry for the delay over the US holiday weekend.

> 226e49cb added a GUC parameter to specify trusted output plugins, and slot creation
> would fail if a give plugin is not listed there.

Right. (pgoutput is in that parameter by default, so the case in
question requires a DBA to remove it and then be surprised at the
results.)

> pg_createsubscriber command creates replication slots with plugin 'pgoutput',
> without checking the GUC. This meant if the plugin name is not specified in the
> parameter, --dry-run mode passes but actual convertion fails.
> It's very surprising for users and should be avoided.

Isn't this the same behavior as for all other permissions issues? We
don't check for
- REPLICATION privs
- permission for FOR ALL TABLES
- CREATE on the target databases
- ownership on a publication to drop
- permission to call pg_log_standby_snapshot()

Looks like all those pass a --dry-run and then fail later.

No worries if we're trying to improve this behavior incrementally; I'm
just trying to understand what we want the standard to be for
pg_createsubscriber behavior going forward.

Thanks,
--Jacob

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2026-09-08 16:40:56 Re: Further cleanup related to statistics import support in postgres_fdw
Previous Message Greg Burd 2026-09-08 16:16:36 Re: Improve error handling in test modules: test_extensible, test_bitmapset