Re: Patch: Implement failover on libpq connect level.

On Fri, Oct 30, 2015 at 11:29:09AM -0400, Christopher Browne wrote:
> On 30 October 2015 at 09:26, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Thu, Oct 29, 2015 at 8:29 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > > On 10/28/15 4:18 AM, Victor Wagner wrote:
> > >> On Mon, 26 Oct 2015 16:25:57 -0400
> > >> Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > >>
> > >>> Also, this assumes that all the components other than host and port
> > >>> are the same. Earlier there was a discussion about why the ports
> > >>> would ever need to be different. Well, why can't the database names
> > >>> be different? I could have use for that.
> > >>
> > >> Because of way postgresql replication is implemented.
> > >
> > > There are multiple types of PostgreSQL replication, and there will be
> > > others in the future.
> >
> > That's true, but doesn't allowing every parameter to be multiply
> > specified greatly increase the implementation complexity for a pretty
> > marginal benefit? I think host and IP would hit 98% of the use cases
> > here.
>
> I think it makes the feature WORSE. I am getting more and more convinced
> that the Correct Solution is for this feature to be handled by submitting
> multiple URIs, and my argument isn't even based on any aspects of
> implementation complexity.
>
> Take as example the case where I have two database servers I want to
> be considered.
>
> a) Database with URI
> postgresql://cbbrowne(at)server-a(dot)example(dot)info:5432/my-first-database
>
> b) Database with URL
> postgresql://robert(at)server-b(dot)example(dot)info:7032/my-second-database
>
> With all the "per-variable multiplicities", this would turn into a
> combinatorial explosion of combinations, some 2^4, or 16 possible servers,
> some of which likely don't exist, and others of which aren't proper (e.g. -
> trying to connect to database a) using robert's credentials).
>
> Possibly some of those combinations are outright improper.

Let's say that the chances of their all both existing and being proper
are close enough to zero not to matter.

> Seems like Best Goodness for Postgres to do something analogous...
> postgresql://cbbrowne(at)server-a(dot)example(dot)info:5432/my-first-database
> postgresql://robert(at)server-b(dot)example(dot)info:7032/my-second-database

Yes.

> Is it a bit long? Sure. But it is unambiguous, and requires *only*
> whitespace parsing to separate the URIs. I'd think it fine for Postgres to
> support this via multiple "-d" options; that would be about as good.

Indeed. Is there any risk of losing ordering information in the
standard command line processing libraries?

> That can cover 100% of cases, and I don't see it needing to interact
> specially with odd bits such as "was that a replication slot?" You can
> always choose to shoot yourself in the foot, but this doesn't spin the
> roulette for you...

An evocative image, if not a pretty one.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate