Buildfarm member lorikeet is still failing the test from commit
32a9c0bdf, but now it's down to the should-have-foreseen-it problem
that the error message isn't what the expected-output file expects.
Let's see if we can get stable results by printing just the SQLSTATE.
I believe we'll reliably see ERRCODE_CONNECTION_FAILURE, since
pgfdw_report_error() will report that for any libpq-originated error.
There may be a better way to do this, but I'd like to get the
buildfarm back to green before we discuss further improvements.
Discussion: https://postgr.es/m/
[email protected]
Discussion: https://postgr.es/m/
2621622.
1602184554@sss.pgh.pa.us
-- If the query detects the broken connection when starting new remote
-- subtransaction, it doesn't reestablish new connection and should fail.
+-- The text of the error might vary across platforms, so don't show it.
CALL terminate_backend_and_wait('fdw_retry_check');
SAVEPOINT s;
+\set VERBOSITY sqlstate
SELECT 1 FROM ft1 LIMIT 1; -- should fail
-ERROR: server closed the connection unexpectedly
- This probably means the server terminated abnormally
- before or while processing the request.
-CONTEXT: remote SQL command: SAVEPOINT s2
+ERROR: 08006
+\set VERBOSITY default
COMMIT;
-- Clean up
DROP PROCEDURE terminate_backend_and_wait(text);
-- If the query detects the broken connection when starting new remote
-- subtransaction, it doesn't reestablish new connection and should fail.
+-- The text of the error might vary across platforms, so don't show it.
CALL terminate_backend_and_wait('fdw_retry_check');
SAVEPOINT s;
+\set VERBOSITY sqlstate
SELECT 1 FROM ft1 LIMIT 1; -- should fail
+\set VERBOSITY default
COMMIT;
-- Clean up