Re: Patch: Implement failover on libpq connect level. - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject Re: Patch: Implement failover on libpq connect level.
Date
Msg-id 0A3221C70F24FB45833433255569204D1F652FC8@G01JPEXMBYT05
Whole thread Raw
In response to Re: Patch: Implement failover on libpq connect level.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Patch: Implement failover on libpq connect level.
List pgsql-hackers
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas
> On Thu, Nov 17, 2016 at 10:08 PM, Craig Ringer <craig@2ndquadrant.com>
> wrote:
> > 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.

I thought you are very strict about performance, so I hesitate to believe you forgive the additional round trip.  libpq
failoveris a new feature in v10, so I think it should provide the best user experience for v10 client+server users from
thestart.  If the concern is the time for development, then support for older releases can be added in a later patch.
 

There are still several months left for v10.  Why don't we try the best?  Could you share the difficulty?


Regards
Takayuki Tsunakawa



pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: Re: Patch: Implement failover on libpq connect level.
Next
From: Amit Kapila
Date:
Subject: Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows