you assumed right that it was host instead of dbname :)
I failed at "anonymising" my connection string...
Note that at the same time, I had java services connected to the same cluster using the jdbc driver without issues.
Regards,
Cyril
Le ven. 14 août 2020 à 09:51, Noah Misch <noah@leadboat.com> a écrit :
On Thu, Aug 13, 2020 at 06:08:14PM -0400, Tom Lane wrote: > Noah Misch <noah@leadboat.com> writes: > > On Wed, Jun 24, 2020 at 08:17:44AM +0000, PG Bug reporting form wrote: > >> I'm connection to pg10 using psql (tried with clients psql 10.11 & psql > >> 12.2) using a connection string such as: > >> psql 'dbname=xxxxx1,xxxxx2,xxxxx3,xxxxx4 target_session_attrs=read-write' > >> > >> the connection to first database (xxxxx1) fail with the error: > >> psql.bin: FATAL: the database system is starting up > >> > >> which is correct according to postgres state on that machine, > >> but then I would expect the psql tries the next server (xxxxx2) with is in > >> the one acceptiong the connection params (target_session_attrs=read-write) > >> instead of the error. > > > I agree.
> I assume that the actual test case involved a comma-separated *host* > (or hostaddr) list, which is what drives multiple connection attempts.
Like you, I assumed that.
> It is true that if we manage to make a connection to a host, but it > then rejects us for some reason, we just give up rather than trying > the next host. The problem with trying to improve that is that it's > very unclear which cases it's actually appropriate to do that for.
That is an obstacle, yes. Assume the connection string has N>=2 entries where, typically, one is read-write and N-1 are read-only. Here's the principle that made me agree with the bug report. It should be possible to "pg_ctl restart" any one host without interrupting clients' ability to form a read-only connection using the multi-host connection string. Currently, the outcome depends on the timing within the restart sequence:
1. fails during shutdown checkpoint 2. succeeds after port closes 3. fails after port opens, during early recovery 4. succeeds after recovery permits read-only connections
That's a bad user experience. I didn't form a proposal for what to do instead, but I doubt we already have the optimum.
> As an example, if you fat-finger the password to host 1, it's unlikely > that silently switching our attention to host 2 would be advisable. > At best, what you'd get is several confusing duplicate messages.
I'd be fine with the duplicate messages. Yeah, if we could divine that the connection attempt failed due to a client typo, it would be nice to stop there. A client can't divine that. If the PostgreSQL servers use pam or ldap authentication, server-side trouble can cause transient authentication failures.
I do seem to recall discussion that rejected retrying on all errors, but I looked and didn't locate it.
