Daniel Farina <daniel@heroku.com> writes:
> On Sat, Aug 27, 2011 at 1:51 PM, Tom Lane <tgl@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.
The difficulty here is that, having failed to fork off a subprocess from
the postmaster, we really can't do much of anything beyond blasting out
a predetermined failure message. We can *not* have the postmaster wait
to see what protocol the client asked for, or we risk denial-of-service
problems from malfunctioning or malicious clients. So there's basically
no solution to be found by altering what it is that the client sends.
> 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.
Yeah. We could possibly hope that the current format of error messages
is sufficiently general that it'll never be obsoleted, or at least will
always be a valid subset of future formats.
regards, tom lane