This came up recently on IRC, not sure if the report there was passed on at all.
ProcessStartupPacket assumes that there will be only one negotiation request for an encrypted connection, but libpq is capable of issuing two: it will ask for GSS encryption first, if it looks like it will be able to do GSSAPI, and if the server refuses that it will ask (on the same connection) for SSL. But ProcessStartupPacket assumes that the packet after a failed negotiation of either kind will be the actual startup packet, so the SSL connection request is rejected with "unsupported version 1234.5679". I'm guessing this usually goes unnoticed because most people are probably not set up to do GSSAPI, and those who are are probably ok with using it for encryption. But if the client is set up for GSSAPI and the server not, then trying to do an SSL connection will fail when it should succeed, and PGGSSENCMODE=disable in the environment (or connect string) is necessary to get the connection to succeed. It seems to me that this is a bug in ProcessStartupPacket, which should accept both GSS or SSL negotiation requests on a connection (in either order). Maybe secure_done should be two flags rather than one? I'm not really familiar with the GSSAPI stuff so probably someone who is should take a look. -- Andrew (irc:RhodiumToad)