From: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: Implement failover on libpq connect level. |
Date: | 2015-09-08 04:29:32 |
Message-ID: | 20150908072932.72f4e974@wagner.wagner.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
В Mon, 07 Sep 2015 17:32:48 +0200
"Daniel Verite" <daniel(at)manitou-mail(dot)org> пишет:
> Victor Wagner wrote:
>
> > It would just take a bit more time for client and a bit more load
> > for server - to make sure that this connection is read-write by
> > issuing
> >
> > show transaction_read_only
> >
> > statement before considering connection useful.
>
> If the purpose of the feature is to wait for a failover to complete,
> shouldn't it check for pg_is_in_recovery() rather than
> transaction_read_only ?
>
Purpose of this feature is to distinguish between master and standby
servers.
This allows failover system to work with standby servers accepting
client connections, and even to create system where read-only clients
can be loadbalanced among several hot backup servers, and read-write
clients work with master, but do not need reconfiguration when
failover happens.
pg_is_in_recovery() is really better. But it seems that chapter 25 of
documentation should be improved and this function mentioned in the
section 25.5.1 (Hot Standby / User Overview)
--
Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2015-09-08 04:58:37 | Re: On-demand running query plans using auto_explain and signals |
Previous Message | Peter Geoghegan | 2015-09-08 04:20:23 | Re: Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY? |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2015-09-08 13:29:12 | Re: Proposal: Implement failover on libpq connect level. |
Previous Message | Daniel Verite | 2015-09-07 15:32:48 | Re: Proposal: Implement failover on libpq connect level. |