Hi Tom, I agree to get detailed error message for each failed host as your patch 0001.
As for patch 0004, find ':' after "could not connect to" may failed when error message like: "could not connect to host "localhost" (::1), port 12345: Connection refused", where p2 will point to "::1" instead of ": Connection refused". But since it's only used for test case, we don't need to filter the error message precisely. ``` ecpg_filter_stderr(const char *resultfile, const char *tmpfile) { ...... char *p1 = strstr(linebuf.data, "could not connect to "); if (p1) { char *p2 = strchr(p1, ':'); if (p2) memmove(p1 + 17, p2, strlen(p2) + 1); } } ``` Thanks, Hubert ________________________________ From: Tom Lane <t...@sss.pgh.pa.us> Sent: Monday, January 11, 2021 10:56 AM To: Hubert Zhang <zhub...@vmware.com> Cc: tsunakawa.ta...@fujitsu.com <tsunakawa.ta...@fujitsu.com>; pgsql-hack...@postgresql.org <pgsql-hack...@postgresql.org> Subject: Re: Multiple hosts in connection string failed to failover in non-hot standby mode I wrote: > I feel pretty good about 0001: it might be committable as-is. 0002 is > probably subject to bikeshedding, plus it has a problem in the ECPG tests. > Two of the error messages are now unstable because they expose > chosen-at-random socket paths: > ... > I don't have any non-hacky ideas what to do about that. The extra detail > seems useful to end users, but we don't have any infrastructure that > would allow filtering it out in the ECPG tests. So far the only solution that comes to mind is to introduce some infrastructure to do that filtering. 0001-0003 below are unchanged, 0004 patches up the ecpg test framework with a rather ad-hoc filtering function. I'd feel worse about this if there weren't already a very ad-hoc filtering function there ;-) This set passes check-world for me; we'll soon see what the cfbot thinks. regards, tom lane