pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dave Cramer <pg@fastcrypt.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: laurenz.albe@cybertec.at, Haribabu Kommi <kommi.haribabu@gmail.com>
Cc: Jing Wang <jingwangian@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>
Subject: Re: Libpq support to connect to standby server as priority
Date: Mon, 14 Jan 2019 17:17:16 -0500
Message-ID: <26251.1547504236@sss.pgh.pa.us> (raw)
In-Reply-To: <CADK3HH+eMdju_peR3ugnu6EYQkZB0vzvqrDQVKxDB2+ea3iQfA@mail.gmail.com>
References: <CAF3+xM+8-ztOkaV9gHiJ3wfgENTq97QcjXQt+rbFQ6F7oNzt9A@mail.gmail.com>
	<CAJrrPGfzSD4kmedadcDx+3vckj_kJ_jAuufgi+NsemTkWSU5Tw@mail.gmail.com>
	<1530710078.2411.29.camel@cybertec.at>
	<CA+TgmobfBaNaMrT5Qx+nQ=JKYYy-VOZ2xxXAhAGUSSWZ=fkm4g@mail.gmail.com>
	<CAJrrPGea1hX5HmZyVzhJ3HbT8x3+2zoNp48HhPVFzQUYy5PU_w@mail.gmail.com>
	<CAJrrPGcMq9YgG-aMzLK051EndUgjdnpp8_dJwJaNDZbu=sS0qQ@mail.gmail.com>
	<CAJrrPGcwt0LLLzDF9c3-zWrESJCJko-HovDOrMobkaWQaJ5YUw@mail.gmail.com>
	<67be09458f276c0c95a4b2a2a383dca9775d19cd.camel@cybertec.at>
	<26890.1542047012@sss.pgh.pa.us>
	<096a642cff0dd68b8157a5f8838e1762d0050d18.camel@cybertec.at>
	<28777.1542386147@sss.pgh.pa.us>
	<CA+TgmoY7hRUJyAsDAwgrJVxNVjPgBD50jBccd5795=KQdNz8fw@mail.gmail.com>
	<CADK3HH+eMdju_peR3ugnu6EYQkZB0vzvqrDQVKxDB2+ea3iQfA@mail.gmail.com>

This patch is marked as "ready for committer", but that characterization
seems way over-optimistic.  It looks like there are several unsettled
questions:

1. The connection parameter name and values are unlike the very similar
feature in pgJDBC.  I think this is a fair complaint.  Now I'm not in love
with "hostRecheckSeconds" --- that seems like a very squishily defined
thing with limited use-case, given Robert's argument that you shouldn't
be using this feature at all for short-lived connections.  And
"loadBalanceHosts" is something we could leave for later.  But it seems
pretty unfortunate not to follow pgJDBC's lead on the main parameter,
"targetServerType=(any | master | secondary | preferSecondary)".

The problem here of course is that whoever invented target_session_attrs
was unconcerned with following that precedent, so what we have is
"target_session_attrs=(any | read-write)".
Are we prepared to add some aliases in service of unifying these names?

2. Whether or not you want to follow pgJDBC's naming, it seems like we
ought to have both "require read only" and "prefer read only" behaviors
in this patch, and maybe likewise "require read write" versus "prefer
read write".

3. We ought to sync this up with whatever's going to happen in
https://commitfest.postgresql.org/21/1090/
at least to the extent of agreeing on what GUCs we'd like to see
the server start reporting.

4. Given that other discussion, it's not quite clear what we should
even be checking.  The existing logic devolves to checking that
transaction_read_only is true, but that's not really the same thing as
"is a master server", eg you might have connected to a master server
under a role that has SET ROLE default_transaction_read_only = false.
(I wonder what pgJDBC is really checking, under the hood.)
Do we want to have modes that are checking hot-standby state in some
fashion, rather than the transaction_read_only state?

			regards, tom lane




view thread (149+ messages)  latest in thread

Message-ID: <26251.1547504236@sss.pgh.pa.us>
Permalink:  ../26251.1547504236@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/26251.1547504236@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pg@fastcrypt.com, robertmhaas@gmail.com, kommi.haribabu@gmail.com, jingwangian@gmail.com, tsunakawa.takay@jp.fujitsu.com
  Subject: Re: Libpq support to connect to standby server as priority
  In-Reply-To: <26251.1547504236@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox