Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

Поиск
Список
Период
Сортировка
От Melanie Plageman
Тема Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
Дата
Msg-id CAAKRu_bLcVxPjrZKQPUfDSWzkfMpud2dewezRCvVy7k52DADVQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.  (Melanie Plageman <melanieplageman@gmail.com>)
Список pgsql-hackers
Дерево обсуждения


On Tue, Sep 12, 2017 at 6:11 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
On Wed, Sep 13, 2017 at 3:48 AM, Elvis Pranskevichus <elprans@gmail.com> wrote:
> I incorporated those bits into your patch and rebased in onto master.
> Please see attached.
>
> FWIW, I think that mixing the standby status and the default
> transaction writability is suboptimal.  They are related, yes, but not
> the same thing.  It is possible to have a master cluster in the
> read-only mode, and with this patch it would be impossible to
> distinguish from a hot-standby replica without also polling
> pg_is_in_recovery(), which defeats the purpose of having to do no
> database roundtrips.

Hi Elvis,

FYI the recovery test 001_stream_rep.pl fails with this patch applied.
You can see that if you configure with --enable-tap-tests, build and
then cd into src/test/recovery and "make check".

The latest patch applies cleanly and builds (I am also seeing the failing TAP tests), however, I have a concern. With a single server set up, when I attempt to make a connection with target_session_attrs=read-write, I get the message 
psql: could not make a suitable connection to server "localhost:5432"
Whereas, when I attempt to make a connection with target_session_attrs=read-only, it is successful.

I might be missing something, but this seems somewhat counter-intuitive. I would expect to specify read-write as target_session_attrs and successfully connect to a server on which read and write operations are permitted. I see this behavior implemented in src/interfaces/libpq/fe-connect.c
Is there a reason to reject a connection to a primary server when I specify 'read-write'? Is this intentional?

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: [HACKERS] Re: issue: record or row variable cannot be part ofmultiple-item INTO list
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] SCRAM in the PG 10 release notes