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: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_createsubscriber does not check output_plugin_libraries
Date: 2026-09-14 23:47:26
Message-ID: CAOYmi+nFptx-1xTxMqatHgRuLAc3JKZo--FzXZvKcrpCjBc=BQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 11, 2026 at 2:45 AM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> > TBH, the code for checking output_plugin_libraries seems to be getting
> > more complicated than I initially expected. But, from my view, it hasn't
> > become complicated and difficult enough to justify leaving the check out,
> > at least *for now*.
>
> OK, so let's keep working on the patch set. Patches in [1] are still valid.
> We can consider again after the patch will be a committable shape.

Sounds good.

> + /*
> + * Should not happen. (Frontend and backend GUC_LIST_QUOTE parsing
> + * have to remain compatible for pg_dump at minimum.)
> + */

I spun for a while on the network compatibility implications of this,
until I realized that pg_createsubscriber isn't going to work if the
source server is a different major version (even though it doesn't
explicitly check the source server's version, AFAICT?). If that's
correct, this code should be fine. I haven't reviewed line-by-line,
but the general approach LGTM.

Thanks!
--Jacob

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-09-14 23:55:47 Re: [PATCH] Explain what the default output_plugin_libraries do
Previous Message Bharath Rupireddy 2026-09-14 23:43:44 Re: Support for 8-byte TOAST values, round two