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

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-31T03:33:51Z
Lists: pgsql-hackers
On Mon, May 31, 2021 at 11:00:55AM +0900, Michael Paquier wrote:
> Yeah.  On the contrary, it could be confusing if one sees an error
> message but there is nothing to worry about, because things are
> working in the scope of what the user wanted at connection time.

In my recent quest to look at GSSAPI builds on Windows, I have bumped
into another failure that's related to this thread.  hamerkop
summarizes the situation here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2021-05-29%2010%3A15%3A42

There are two failures like this one as errorMessage piles up on
failures, as of connect/test5:
-[NO_PID]: ECPGconnect: connection to server failed: FATAL:  database
 "regress_ecpg_user2" does not exist
+[NO_PID]: ECPGconnect: connection to server failed: could not
 initiate GSSAPI security context: Unspecified GSS failure.  Minor
 code may provide more information: Credential cache is empty
+connection to server failed: FATAL:  database "regress_ecpg_user2"
 does not exist 
--
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.