Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
От | Jaime Casanova |
---|---|
Тема | Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable. |
Дата | |
Msg-id | CAJGNTeNkuHQrG3MMcWd9Z01XTXDTP504xQeDrXbwD6aa7cgbGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [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.
|
Список | pgsql-hackers |
On 18 March 2017 at 14:01, Elvis Pranskevichus <elprans@gmail.com> wrote: > On Saturday, March 18, 2017 3:33:16 AM EDT Michael Paquier wrote: >> >> Why adding a good chunk of code instead of using pg_is_in_recovery(), >> which switches to false once a server exits recovery? > > That requires polling the database continuously, which may not be > possible or desirable. > > My main motivation here is to gain the ability to manage a pool of > connections in asyncpg efficiently. A part of the connection release > protocol is "UNLISTEN *;", which the server in Hot Standby would fail to > process. Polling the database for pg_is_in_recovery() is not feasible > in this case, unfortunately. > Sorry, i still don't understand the motivation for this. At one point you're going to poll for the value of the GUC in pg_settings, no? Or how are you going to know the current value of the GUC that makes it different to just poll for pg_is_in_recovery()? -- Jaime Casanova www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: