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

Поиск
Список
Период
Сортировка
От Euler Taveira
Тема Re: two_phase commit parameter used in subscription for a publication which is on < 15.
Дата
Msg-id 6e3fc103-9670-4514-8d9b-d447b07e2bab@www.fastmail.com
обсуждение исходный текст
Ответ на two_phase commit parameter used in subscription for a publication which is on < 15.  (tushar <tushar.ahuja@enterprisedb.com>)
Ответы Re: two_phase commit parameter used in subscription for a publication which is on < 15.  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: .ready and .done files considered harmful
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)