Re: pg_createsubscriber does not check output_plugin_libraries

> On Sep 9, 2026, at 00:33, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>
> 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.
>

That’s a fair point. The distinction I had in mind is that this patch explicitly adds a check for output_plugin_libraries to make --dry-run more useful. But when the caller cannot read that setting, pg_createsubscriber simply does not have enough information to perform the check. Would it make sense to print a warning in that case, rather than silently letting --dry-run succeed?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/