Обсуждение: two_phase commit parameter used in subscription for a publication which is on < 15.
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"
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
Re: two_phase commit parameter used in subscription for a publication which is on < 15.
От
"Euler Taveira"
Дата:
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.
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.