On Sat, Aug 27, 2011 at 1:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > A more long-range point about it is that the next time we make a > protocol version bump that affects the format of error messages, > the problem comes right back. It'd be better if the message somehow > indicated that the server hadn't made any attempt to match the client > protocol version. I guess if we went up to 3.0 protocol, we could > include a SQLSTATE value in the message and libpq could test that before > making assumptions.
Hmm. What do you think about the way ssh handles support and negotiation of cipher methods between client and server: in that case, I believe both client and server advertise what ciphers they are willing to accept. Changing the format of that negotiation procedure would be a pain, but hopefully that could be gotten pretty much right the first time. Right now, my understanding is libpq sends a version to the server, but doesn't really receive a list of supported formats in response, from this thread it seems what happens is if an old-style message is returned then it's presumed the server can't handle the new versions, which is not necessarily true. The server seems to written with the sensible assumption that it should use the oldest sensible message format to get the idea across to libpq of as many versions as possible, but libpq is taking a byproduct of the *way* the message/error is sent to learn something about the server's supported versions, and using that to affect more behavior. So perhaps one solution for the distant future is to respond with protocol versions so that libpq need not rely on guessing based on a particular message style it receives. Alternatively, could it make sense to just always report fork failure in the newest libpq version and broadcast failures in each protocol version's format, one after another? This presumes that old libpqs are forward-compatible to skip un-understood messages forever, though, which is saying a lot about the future...and that seems to be affecting ancient libpqs, as per your message. Please correct me; my understandings of the of the startup process have been hastily acquired from the documentation. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
