On 18 March 2017 at 14:01, Elvis Pranskevichus <elpr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
