Horton

Re: Libpq support to connect to standby server as priority

Dave Cramer <pg@fastcrypt.com>

View thread View on postgr.es
From: Dave Cramer <pg@fastcrypt.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, laurenz.albe@cybertec.at, Haribabu Kommi <kommi.haribabu@gmail.com>, Jing Wang <jingwangian@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Date: 2018-11-21T14:14:52Z
Lists: pgsql-hackers 
On Wed, 21 Nov 2018 at 09:05, Robert Haas <robertmhaas@gmail.com> wrote:

> On Fri, Nov 16, 2018 at 11:35 AM Tom Lane <tgl@sss.pgh.pa.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

davec@postgresintl.com
www.postgresintl.com

>
>

Commits

  1. Make test_target_session_attrs more robust against connection failure.

  2. Extend the abilities of libpq's target_session_attrs parameter.

  3. Mark default_transaction_read_only as GUC_REPORT.

  4. Introduce a new GUC_REPORT setting "in_hot_standby".

  5. Avoid spamming the client with multiple ParameterStatus messages.

  6. Avoid harmless Valgrind no-buffer-pin errors.

  7. Restructure libpq code to remove some duplicity

  8. libpq: Add target_session_attrs parameter.