So 8bf58c0d9 immediately blew up in the buildfarm, with eg this
on jaguarundi:
***************
*** 130,136 **** ALTER SERVER loopback OPTIONS (SET dbname 'no such database'); SELECT c3, c4 FROM ft1 ORDER BY c3, c1
LIMIT1; -- should fail ERROR: could not connect to server "loopback"
! DETAIL: FATAL: database "no such database" does not exist DO $d$ BEGIN EXECUTE $$ALTER SERVER loopback
--- 130,136 ---- ALTER SERVER loopback OPTIONS (SET dbname 'no such database'); SELECT c3, c4 FROM ft1 ORDER BY c3, c1
LIMIT1; -- should fail ERROR: could not connect to server "loopback"
! DETAIL: FATAL: Datenbank ?no such database? existiert nicht DO $d$ BEGIN EXECUTE $$ALTER SERVER
loopback
***************
I had not realized (or forgot) that postgres_fdw allows the remote
end to run in whatever lc_messages locale is default for the remote
installation. It's a bit surprising that none of the existing test
cases expose any remote-side messages directly, but evidently not.
We could stabilize this test result by forcing lc_messages = C in
the foreign server options. However, that would lose regression
coverage of situations where the remote locale is different, which
doesn't seem like a terribly good thing.
Another option is to temporarily set VERBOSITY to "terse" so that
the DETAIL is suppressed from the test output. But then we don't
really know why the connection failed, so that could mask issues
that the test case ought to find, too.
Maybe set lc_messages = C in the options only for the duration
of these new test cases?
regards, tom lane