Thread

1. two_phase commit parameter used in subscription for a publication which is on < 15.

   tushar <tushar.ahuja@enterprisedb.com> — 2021-09-27T07:09:51Z

   Hi,
   
   Please refer to this scenario
   CASE 1- HEAD (publication)-> HEAD (Subscription)
   CASE 2 - PG 14 (Publication) ->HEAD (Subscription)
   
   Test-case -
   Publication  = create table t(n int); create publication p for table t;
   Subscription = create table t(n int);
   create subscription  s connection 'dbname=postgres host=localhost '
   PUBLICATION p WITH (two_phase=1);
   
   Result-
   CASE 1-
   postgres=# select two_phase from pg_replication_slots where slot_name='s';
    two_phase
   -----------
    t
   (1 row)
   
   
   CASE 2 -
   postgres=# select two_phase from pg_replication_slots where slot_name='s';
    two_phase
   -----------
    f
   (1 row)
   
   so are we silently ignoring this parameter as it is not supported on v14 ?
   and if yes then why not we just throw a message like
   ERROR:  unrecognized subscription parameter: "two_phase"
   
   --
   regards,tushar
   EnterpriseDB  https://www.enterprisedb.com/
   The Enterprise PostgreSQL Company
   

2. Re: two_phase commit parameter used in subscription for a publication which is on < 15.

   Euler Taveira <euler@eulerto.com> — 2021-09-27T18:09:49Z

   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
   EDB   https://www.enterprisedb.com/
   

3. Re: two_phase commit parameter used in subscription for a publication which is on < 15.

   Amit Kapila <amit.kapila16@gmail.com> — 2021-09-28T03:01:45Z

   On Mon, Sep 27, 2021 at 11:40 PM Euler Taveira <euler@eulerto.com> wrote:
   >
   > 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.
   >
   
   True, and the same behavior was already there for 'binary' and
   'streaming' options. Shall we document this instead of DEBUG message
   or probably along with DEBUG message?
   
   -- 
   With Regards,
   Amit Kapila.