> On Sep 9, 2026, at 00:33, Jacob Champion <[email protected]>
> wrote:
>
> On Thu, Sep 3, 2026 at 8:49 PM Hayato Kuroda (Fujitsu)
> <[email protected]> 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/
