Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
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-06-09T16:05:10Z
Lists: pgsql-hackers

Attachments

I wrote:
> ...  I'd be okay with dropping that test; or maybe we could
> fix things so that the default case succeeds?

Here's a draft patch that renames regress_ecpg_user2 to ecpg2_regression,
which matches the name of one of the databases used, allowing the test
cases with defaulted database name to succeed.  That gets rid of one of
the problematic diffs.  As it stood, though, that meant that connect/test5
wasn't exercising the connection-failure code path at all, which didn't
seem like what we want.  So I adjusted the second place that had been
failing to again fail on no-such-database, and stuck in gssencmode=disable
so that we shouldn't get any test diff on hamerkop.

			regards, tom lane

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.