Re: pg_dump versus ancient server versions

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> Proposal:

> * pg_dump and psql will maintain compatibility with servers at least
> ten major releases back.
> * We keep old major release branches buildable as long as a new major
> release that has support for that old release is under support.

> This assumes a yearly major release cadence.

If the point is to not have to count dates carefully, why does the cadence
matter?

> I say "at least" because I wouldn't go around aggressively removing
> support for old releases. If $NEW is supposed to support 9.5 but
> there is code that says `if (version > 9.4)`, I would not s/9.4/9.5/
> that unless that code is touched for other reasons.

I can get behind something roughly like this, but I wonder if it wouldn't
be better to formulate the policy in a reactive way, i.e. when X happens
we'll do Y. If we don't plan to proactively remove some code every year,
then it seems like the policy really is more like "when something breaks,
then we'll make an attempt to keep it working if the release is less than
ten majors back; otherwise we'll declare that release no longer
buildable."

However, this'd imply continuing to test against releases that are out of
the ten-year window but have not yet been found to be broken. Not sure
if that's a useful expenditure of test resources or not.

> Buildable for this purpose means just enough that you can use it to
> test pg_dump and psql. This probably includes being able to run make
> installcheck and use pg_dump and psql against the regression database.
> It does not require support for any additional build-time options that
> are not required for this purpose (e.g., new OpenSSL releases).

I agree with the idea of being conservative about what outside
dependencies we will worry about for "buildable" old versions.
(Your nearby message about Python breakage is a good example of
why we must limit that.) But I wonder about, say, libxml or libicu,
or even if we can afford to drop all the non-plpgsql PLs. An
example of why that seems worrisome is that it's not clear we'd
have any meaningful coverage of transforms in pg_dump with no PLs.
I don't have any immediate proposal here, but it seems like an area
that needs some thought and specific policy.

> Example under this proposal:

> PG 15 supports PG 9.2
> PG 14 supports PG 9.1
> PG 13 supports PG 9.0
> PG 12 supports PG 8.4
> PG 11 supports PG 8.3
> PG 10 supports PG 8.2

I was going to express concern about having to resurrect branches
back to 8.2, but:

> In practice, the effort can focus on keeping the most recent cutoff
> release buildable. So in the above example, we really only need to
> keep PG >=9.2 buildable to support ongoing development. The chances
> that some needs to touch code pertaining to older versions in
> backbranches is lower, so those really would need to be dealt with
> very rarely.

OK. Also, when you do need to check that, there are often other ways
than rebuilding the old branch on modern platforms --- people may
well have still-executable builds laying about, even if rebuilding
from source would be problematic.

regards, tom lane