With recent versions of postgres, I started to see following test issue:
Failures: 1) PG::Connection server ping returns correct response when ping connection arguments are wrong Failure/Error: expect( ping ).to eq( PG::PQPING_NO_ATTEMPT ) expected: 3 got: 2 (compared using ==) # ./spec/pg/connection_spec.rb:1104:in `block (3 levels) in <top (required)>' # ./spec/helpers.rb:31:in `block in included' Finished in 54.74 seconds (files took 0.50386 seconds to load) 375 examples, 1 failure, 1 pending
I originally reported this against postgres in Fedora:
and this was the response:
Tom Lane 2018-11-15 17:46:31 CET
[ pokes around... ] This is a behavioral change in PQping as a consequence of upstream commit 6953daf08e6b1ef333758f6cda54de228212f12e. The given string is in fact wrong, because 'localhost' is not a valid value for "port" - that has to be a port number. However, validation of both the host name and port number have been postponed to the connection phase as a consequence of the fact that they're now allowed to be lists. That means that instead of getting a "no attempt" result, you get a "no response" result; "no attempt" is only returned if initial parsing of the string fails.
I don't think this is a bug exactly; it's a matter of the test exercising an unspecified corner case and expecting a particular error code rather than some other error code. If you want something that will provoke PQPING_NO_ATTEMPT reliably, I'd suggest using a connection string that's syntactically malformed or attempts to set an unrecognized parameter name.
Now I wonder what is your view :)