"PG::Connection server ping returns correct response when ping connection" fails with recent PG

Issue #287 resolved
Vít Ondruch
created an issue

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:

https://bugzilla.redhat.com/show_bug.cgi?id=1650234

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 :)

Comments (4)

  1. Log in to comment