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 LIMIT 1; -- 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 LIMIT 1; -- 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
