{"shas":[["d3dcf7ae7b94218f1ebfdb04c319840c253416d9","ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","Don't assume that \"E\" response to NEGOTIATE_SSL_CODE means pre-7.0 server.\n\nThese days, such a response is far more likely to signify a server-side\nproblem, such as fork failure.  Reporting \"server does not support SSL\"\n(in sslmode=require) could be quite misleading.  But the results could\nbe even worse in sslmode=prefer: if the problem was transient and the\nnext connection attempt succeeds, we'll have silently fallen back to\nprotocol version 2.0, possibly disabling features the user needs.\n\nHence, it seems best to just eliminate the assumption that backing off\nto non-SSL/2.0 protocol is the way to recover from an \"E\" response, and\ninstead treat the server error the same as we would in non-SSL cases.\n\nI tested this change against a pre-7.0 server, and found that there\nwas a second logic bug in the \"prefer\" path: the test to decide whether\nto make a fallback connection attempt assumed that we must have opened\nconn->ssl, which in fact does not happen given an \"E\" response.  After\nfixing that, the code does indeed connect successfully to pre-7.0,\nas long as you didn't set sslmode=require.  (If you did, you get\n\"Unsupported frontend protocol\", which isn't completely off base\ngiven the server certainly doesn't support SSL.)\n\nSince there seems no reason to believe that pre-7.0 servers exist anymore\nin the wild, back-patch to all supported branches.","Tom Lane"]],"ref":"refs/heads/REL8_3_STABLE","size":1,"head":"d3dcf7ae7b94218f1ebfdb04c319840c253416d9","push_id":40863668}