Re: two_phase commit parameter used in subscription for a publication which is on < 15. - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: two_phase commit parameter used in subscription for a publication which is on < 15.
Date
Msg-id 6e3fc103-9670-4514-8d9b-d447b07e2bab@www.fastmail.com
Whole thread Raw
In response to two_phase commit parameter used in subscription for a publication which is on < 15.  (tushar <tushar.ahuja@enterprisedb.com>)
Responses Re: two_phase commit parameter used in subscription for a publication which is on < 15.  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Mon, Sep 27, 2021, at 4:09 AM, tushar wrote:
so are we silently ignoring this parameter as it is not supported on v14 ?
Yes. Because two_phase is a supported parameter for v15 (your current
subscriber).  The issue is that this parameter are not forwarded to publisher
because its version (v14) does not support it. Since we do not have a
connection before parse_subscription_options(), publisher server version is
unknown. Hence, it does not know if that specific parameter is supported on
publisher. I'm not sure it is worth parsing the options again after a
replication connection is available just to check those parameters that don't
work on all supported server versions.

IMO we can provide messages during the connection (see
libpqrcv_startstreaming()) instead of while executing CREATE/ALTER
SUBSCRIPTION. Something like:

         if (options->proto.logical.twophase &&
             PQserverVersion(conn->streamConn) >= 150000)
             appendStringInfoString(&cmd, ", two_phase 'on'");
         else if (options->proto.logical.twophase)
             ereport(DEBUG1,
                     (errmsg_internal("parameter \"two_phase\" is not supported on the publisher")));

It is a DEBUG message because it can be annoying when the subscriber cannot
connect to the publisher.

The output plugin also raises an error if the subscriber sends the two_phase
parameter. See pgoutput_startup(). The subscriber could probably send all
parameters and the output plugin would be responsible to report an error. I
think the author decided to not do it because it is not an user-friendly
approach.


--
Euler Taveira

pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: .ready and .done files considered harmful
Next
From: Mark Dilger
Date:
Subject: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)