Re: Multiple hosts in connection string failed to failover in non-hot standby mode
Tom Lane <tgl@sss.pgh.pa.us>
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-09-13T20:09:26Z
Lists: pgsql-hackers
Attachments
- clear-errorMessage-upon-successful-connection.patch (text/x-diff) patch
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
Commits
-
Clear conn->errorMessage at successful completion of PQconnectdb().
- 896a0c44f93b 14.0 landed
- 138531f1bbc3 15.0 landed
-
Avoid ECPG test failures in some GSS-capable environments.
- 9bb5eecce645 14.0 landed
-
Try next host after a "cannot connect now" failure.
- c1d589571c49 14.0 landed
-
Uniformly identify the target host in libpq connection failure reports.
- 52a10224e3cc 14.0 landed
-
Allow pg_regress.c wrappers to postprocess test result files.
- 800d93f314b0 14.0 landed
-
In libpq, always append new error messages to conn->errorMessage.
- ffa2e4670123 14.0 landed