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

Michael Paquier <michael@paquier.xyz> writes:
> On Sun, May 30, 2021 at 08:25:00PM -0500, Justin Pryzby wrote:
>> ..But I think it's not useful to put details into errorMessage on success,
>> unless you're going to document that.  It would never have occurred to me to
>> look there, or that it would even be safe.

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

I got around to looking at this issue today, and verified that only one
place needs to be changed, as attached.

Although I was initially thinking that maybe we should leave the code
as-is, I now agree that resetting errorMessage is a good idea, because
what tends to be in it at this point is something like

"connection to server on socket "/tmp/.s.PGSQL.5432" failed: "

(ie the string made by emitHostIdentityInfo).  Anybody who does
look at that is likely to be confused, because the connection
*didn't* fail.

There might be some value in my original idea of preserving a trace of
the servers we tried before succeeding.  But it would take additional
work to present it in a non-confusing way, and given the lack of any
field requests for that, I'm not excited about doing it right now.
(One could also argue that it ought to get tied into the PQtrace
facilities somehow, rather than being done in this ad-hoc way.)

            regards, tom lane

diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 49eec3e835..b288d346f9 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -3654,6 +3654,13 @@ keep_going:                        /* We will come back to here until there is
                 /* We can release the address list now. */
                 release_conn_addrinfo(conn);

+                /*
+                 * Contents of conn->errorMessage are no longer interesting
+                 * (and it seems some clients expect it to be empty after a
+                 * successful connection).
+                 */
+                resetPQExpBuffer(&conn->errorMessage);
+
                 /* We are open for business! */
                 conn->status = CONNECTION_OK;
                 return PGRES_POLLING_OK;