Re: Is it time to kill support for very old servers?

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Greg Stark <stark(at)mit(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>