From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, Peter van Hardenberg <pvh(at)pvh(dot)ca>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch: Implement failover on libpq connect level. |
Date: | 2016-11-18 17:29:19 |
Message-ID: | CA+TgmoarEYcF7mj+2TFqJicdgvd1NwCe5O1DYt0WVeBzJi=D0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
On Thu, Nov 17, 2016 at 10:08 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 17 November 2016 at 10:57, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Nov 16, 2016 at 9:00 PM, Tsunakawa, Takayuki
>> <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
>>> Do we really want to enable libpq failover against pre-V10 servers? I don't think so, as libpq is a part of PostgreSQL and libpq failover is a new feature in PostgreSQL 10. At least, as one user, I don't want PostgreSQL to sacrifice another round trip to establish a connection. As a developer, I don't want libpq code more complex than necessary (the proposed patch adds a new state to the connection state machine.) And I think it's natural for the server to return the server attribute (primary/standby, writable, etc.) as a response to the Startup message like server_version, standard_conforming_strings and server_encoding.
>>
>> Well, generally speaking, a new feature that works against older
>> server is better than one that doesn't. Of course, if that entails
>> making other compromises then you have to decide whether it's worth
>> it, but SELECT pg_is_in_recovery() and SHOW transaction_read_only
>> exist in older versions so if we pick either of those methods then it
>> will just work. If we decide to invent some completely new method of
>> distinguishing masters from standbys, then it might not, but that
>> would be a drawback of such a choice, not a benefit.
>
> We can and probably should have both.
>
> If the server tells us on connect whether it's a standby or not, use that.
>
> Otherwise, ask it.
>
> That way we don't pay the round-trip cost and get the log spam when
> talking to newer servers that send us something useful in the startup
> packet, but we can still query it on older servers. Graceful fallback.
>
> Every round trip is potentially very expensive. Having libpq do them
> unnecessarily is bad.
True, but raising the bar for this feature so that it doesn't get done
is also bad. It can be improved in a later patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-11-18 17:33:26 | Re: Unlogged tables cleanup |
Previous Message | Robert Haas | 2016-11-18 17:24:30 | Re: Snapshot too old logging |
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-11-19 01:23:43 | Re: Patch: Implement failover on libpq connect level. |
Previous Message | Craig Ringer | 2016-11-18 03:08:20 | Re: Patch: Implement failover on libpq connect level. |