Re: Is it time to kill support for very old servers? - Mailing list pgsql-hackers
| From | Steve Crawford |
|---|---|
| Subject | Re: Is it time to kill support for very old servers? |
| Date | |
| Msg-id | CAEfWYyykL9JGCZuAAM5vL60uys8+xFRyHbM88auL3EurRwwQaw@mail.gmail.com Whole thread Raw |
| In response to | Re: Is it time to kill support for very old servers? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: Is it time to kill support for very old servers?
(Jim Nasby <Jim.Nasby@BlueTreble.com>)
|
| List | pgsql-hackers |
This thread gets me thinking about the definition of "support." While support in practice seems to primarily relate to fixes/updates to the supported version itself it could just as well apply to interoperability support by newer versions.
Given that the standard PostgreSQL upgrade process involves upgrading clients first and using pg_dump from the newer version, it is reasonable to assume that the clients/utilities for a given version would support interacting with any prior version that was not EOL at the time the new major version is released.
In other words, 9.6 was released last month, the same month that 9.1 was EOL, so 9.6 clients should work with 9.1 through 9.6 servers but from my perspective there is no need to *guarantee* that 10 would do so. The standard caveats apply. A new version *might* work for an unsupported older version but no assurance is offered.
This is effectively a 5-year upgrade "grace period" *after* the EOL date of a given version which seems plenty generous.
Defining the term of backward compatibility support might be useful in the future when these types of questions arise.
Cheers,
Steve
On Fri, Oct 7, 2016 at 9:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Greg Stark <stark@mit.edu> writes:
>>> For another there may be binary-only applications or drivers out there
>>> that are using V2 for whatever reason.
>> The problem with letting it just sit there is that we're not, in fact,
>> testing it. If we take the above argument seriously then we should
>> provide some way to configure libpq to prefer V2 and run regression
>> tests in that mode. Otherwise, if/when we break it, we'll never know it
>> till we get field reports.
> I agree with that. I think it would be fine to keep V2 support if
> somebody wants to do the work to let us have adequate test coverage,
> but if nobody volunteers I think we might as well rip it out. I don't
> particularly enjoy committing things only to be told that they've
> broken something I can't test without unreasonable effort.
When I wrote the above I was thinking of an essentially user-facing
libpq feature, similar to the one JDBC has, to force use of V2 protocol.
But actually, for testing purposes, I don't think that's what we want.
Any such feature would fail to exercise libpq's logic for falling back
from V3 to V2 when it connects to an old server, which is surely something
we'd like to test without actually having a pre-7.4 server at hand.
So what I'm thinking is it'd be sufficient to do something like
this in pqcomm.h:
+#ifndef FORCE_OLD_PROTOCOL
#define PG_PROTOCOL_LATEST PG_PROTOCOL(3,0)
+#else /* make like a pre-7.4 server for testing purposes */
+#define PG_PROTOCOL_LATEST PG_PROTOCOL(2,0)
+#endif
which would cause the server to reject 3.0 requests just as if it were
ancient. Then we could test with that #define, maybe have a buildfarm
critter doing it. (This might break pqmq.c though, so we might need
to work slightly harder than this.)
Also, I realized while perusing this that the server still has support
for protocol 1.0 (!). That's *definitely* dead code. There's not much
of it, but still, I'd rather rip it out than continue to pretend it's
supported.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
pgsql-hackers by date: