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

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
Дата
Msg-id CABUevEwMnajDG-hpiGgy+U8DL2tMZgfyVU40vH1U1LH88cC0DQ@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.  (Elvis Pranskevichus <elprans@gmail.com>)
Ответы Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Wed, Apr 5, 2017 at 6:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Mar 23, 2017 at 4:50 AM, Magnus Hagander <magnus@hagander.net> wrote:
> One thing we might want to consider around this -- in 10 we have
> target_session_attrs=read-write (since
> 721f7bd3cbccaf8c07cad2707826b83f84694832), which will issue a SHOW
> transaction_read_only on the connection.
>
> We should probably consider if there is some way we can implement these two
> things the same way. If we're inventing a new variable that gets pushed on
> each connection, perhaps we can use that one and avoid the SHOW command?

I think that would be a good idea.  It was, in fact, proposed to do
exactly that as part of the patch that added
target_session_attrs=read-write, but we ended up not doing anything
about it because the SHOW mechanism would still be needed when
connecting to pre-10 versions of PostgreSQL.  Therefore, it seemed
like a separate improvement.  But if we're adding a GUC_REPORT value
that could be used for the same or a similar purpose, I think it would
make sense to consider revising that mechanism to leverage it as well,
obviously only on releases that have the GUC.


Based on that we seem to agree here, should we add this as an open item? Clearly if we want to change this, we should do so before 10.

I also came up with another case where the current one won't work but it could be really useful -- if we make a replication connection (with say pg_receivewal) it would be good to be able to say "i want the master" (or "i want a standby") the same way. And that will fail today if it needs SHOW to work, right?

So having it send that information across in the startup package when talking to a 10 server, but falling back to using SHOW if talking to an earlier server, would make a lot of sense I think. 


--

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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: [HACKERS] Vacuum full stats reporting
Следующее
От: Aleksander Alekseev
Дата:
Сообщение: Re: [HACKERS] [PATCH] Document the order of changing certainsettings when using hot-standby servers