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 <tgl@sss.pgh.pa.us>
Sent: Monday, January 11, 2021 10:56 AM
To: Hubert Zhang <zhubert@vmware.com>
Cc: tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com>; pgsql-hackers@postgresql.org <pgsql-hackers@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
