Horton

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

Daniel Gustafsson <daniel@yesql.se>

View thread View on postgr.es
From: Daniel Gustafsson <daniel@yesql.se>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-17T11:06:51Z
Lists: pgsql-hackers 
> On 11 May 2021, at 09:29, Michael Paquier <michael@paquier.xyz> wrote:

> 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.

Agreed, given how conservative we typically are with backwards compatibility it
seems a too thin benefit to warrant potential breakage.

My vote would too be to restore the behavior by clearing conn->errorMessage.

--
Daniel Gustafsson		https://vmware.com/

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.