summaryrefslogtreecommitdiff
path: root/configure
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2011-08-27 16:37:22 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2011-08-27 16:37:22 -0400
commita2d9f9478e3cc37e534681f702724345050f9ec7 (patch)
tree0ec8174a0a6d34733e3142a9715bc92a11f2b870 /configure
parentbb42ad1231f4e9fa4c774e797882bf2d5a7f8f58 (diff)
downloadpostgresql-a2d9f9478e3cc37e534681f702724345050f9ec7.tar.gz
Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server.
These days, such a response is far more likely to signify a server-side problem, such as fork failure. Reporting "server does not support SSL" (in sslmode=require) could be quite misleading. But the results could be even worse in sslmode=prefer: if the problem was transient and the next connection attempt succeeds, we'll have silently fallen back to protocol version 2.0, possibly disabling features the user needs. Hence, it seems best to just eliminate the assumption that backing off to non-SSL/2.0 protocol is the way to recover from an "E" response, and instead treat the server error the same as we would in non-SSL cases. I tested this change against a pre-7.0 server, and found that there was a second logic bug in the "prefer" path: the test to decide whether to make a fallback connection attempt assumed that we must have opened conn->ssl, which in fact does not happen given an "E" response. After fixing that, the code does indeed connect successfully to pre-7.0, as long as you didn't set sslmode=require. (If you did, you get "Unsupported frontend protocol", which isn't completely off base given the server certainly doesn't support SSL.) Since there seems no reason to believe that pre-7.0 servers exist anymore in the wild, back-patch to all supported branches.
Diffstat (limited to 'configure')
0 files changed, 0 insertions, 0 deletions