RE: pg_createsubscriber does not check output_plugin_libraries

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Jacob Champion' <jacob(dot)champion(at)enterprisedb(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-16 05:35:03
Message-ID: TYRPR01MB12845F38A9E0ACF1487EA8F7EF5B92@TYRPR01MB12845.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Jacob,

> > + /*
> > + * 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?).

Your understanding is correct. IIUC, pg_createsubscriber ensures that
1) the major version of the target server is same as the pg_createsubscriber's one, and
2) the target is working as a hot standby of a source.

These points ensure that all source, target and the executable have a same major
versions.

> If that's
> correct, this code should be fine. I haven't reviewed line-by-line,
> but the general approach LGTM.

OK. But the comment can be simpler just like "Should not happen". IIRC pg_dump
command is not used here.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2026-09-16 05:47:16 Re: Archive-fed logical decoding: pausing recovery on slot conflict
Previous Message Michael Paquier 2026-09-16 05:17:37 Re: Refactor code around GUC default_toast_compression