Re: Cryptic error message in low-memory conditions

On Sat, Aug 27, 2011 at 1:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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