Re: Libpq support to connect to standby server as priority

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, laurenz(dot)albe(at)cybertec(dot)at, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Jing Wang <jingwangian(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Subject: Re: Libpq support to connect to standby server as priority
Date: 2018-11-21 14:14:52
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Wed, 21 Nov 2018 at 09:05, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, Nov 16, 2018 at 11:35 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Oh! The reason I assumed it wasn't doing that is that such a behavior
> > seems completely insane. If the point is to keep down the load on your
> > master server, then connecting only to immediately disconnect is not
> > a friendly way to do that --- even without counting the fact that you
> > might later come back and connect again.
> That seems like a really weak argument. Opening a connection to the
> master surely isn't free, but it must be vastly cheaper than the cost
> of the queries you intend to run. I mean, no reasonable production
> user of PostgreSQL opens a connection, runs one or two short queries,
> and then closes the connection. You open a connection and keep it
> open for minutes, hours, days, or longer, running hundreds, thousands,
> or millions of queries. The cost of checking whether you've got a
> master or a standby is a drop in the bucket.
> And, I mean, if there's some scenario where what I just said isn't
> true, well then don't use this feature in that particular case.
And to enforce Robert's argument even further almost every pool
implementation I am aware of
has a keep alive query. So why not use the opportunity to check to see if
is a primary or standby at the same time

Dave Cramer



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Glapa 2018-11-21 14:26:42 Re: dsa_allocate() faliure
Previous Message David Rowley 2018-11-21 14:13:36 Re: Small performance tweak to run-time partition pruning