Re: Cryptic error message in low-memory conditions

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sat, Aug 27, 2011 at 01:59, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Now, seeing as how NEGOTIATE_SSL_CODE has been understood by every build
>> since PG 7.0, I believe that this is dead code and we could remove it;
>> it seems exceedingly unlikely that any modern build of libpq will ever
>> be used to talk to a server that responds to that with "E".

> What will be the result if you do use the modern libpq against that?

I'll check it after I write the patch, but what I'd expect to happen is
that libpq would fail the connection and report the server's error
message, which would be something like "unrecognized protocol version
number". Anybody who did complain of this could be told to use
sslmode=disable when talking to the ancient server.

> Anyway - that's 5 *unsupported* versions back.

More to the point, it's been a very very long time since we've heard of
anyone using a server older than 7.2. (And there's a good reason for
that, which is that 7.2 was the first version that wouldn't go belly-up
at 4 billion transactions.)

> In fact, when do we reach the point that we can remove all the support
> for the v2 protocol completely? (this would obviously not be as a
> bugfix, but perhaps in 9.2)? Is there any particular reason we need to
> support both anymore? At least in the client?

Fair question. We *have* still heard of people using 7.2/7.3, I think.
Another point here is that there are JDBC people intentionally forcing
protocol version 2 as a means of controlling prepared-statement plan
lifespan. I hope that the auto-replan code that I intend to get into
9.2 will provide a better answer for those folks, but removing the
workaround at the same time might be a tad premature.

So my feeling is "not quite yet, maybe in a couple more years".

regards, tom lane