Horton

Re: Multiple hosts in connection string failed to failover in non-hot standby mode

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Hubert Zhang <zhubert@vmware.com>, tsunakawa.takay@fujitsu.com, pgsql-hackers@postgresql.org, Andreas Seltenreich <seltenreich@gmx.de>, Bruce Momjian <bruce@momjian.us>
Date: 2021-05-11T07:29:28Z
Lists: pgsql-hackers 
On Thu, May 06, 2021 at 01:22:27PM -0400, Tom Lane wrote:
> Hm.  I'd debated whether to clear conn->errorMessage at the end of
> a successful connection sequence, and decided not to on the grounds
> that it might be interesting info (eg it could tell you why you
> ended up connected to server Y and not server X).  But perhaps
> it's too much of a compatibility break for this small benefit.
> 
> I'm curious though why it took this long for anyone to complain.
> I'd supposed that people were running sqlsmith against HEAD on
> a pretty regular basis.

FWIW, I think that the case of getting some information about any
failed connections while a connection has been successfully made
within the scope of the connection string parameters provided by the
user is rather thin, and I really feel that this is going to cause
more pain to users than this is worth it.  So my vote would be to
clean up conn->errorMessage after a successful connection.

Now, I would not mind either if we finish by taking a decision here
after beta1, to see if there are actual complains on the matter based
on the feedback we get.
--
Michael

Commits

  1. Clear conn->errorMessage at successful completion of PQconnectdb().

  2. Avoid ECPG test failures in some GSS-capable environments.

  3. Try next host after a "cannot connect now" failure.

  4. Uniformly identify the target host in libpq connection failure reports.

  5. Allow pg_regress.c wrappers to postprocess test result files.

  6. In libpq, always append new error messages to conn->errorMessage.