Re: pg_dump versus ancient server versions - Mailing list pgsql-hackers

On Mon, Dec 6, 2021 at 4:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Right.  The question that's on the table is how much is the right
> amount of maintenance.  I think that back-patching user-visible bug
> fixes, for example, is taking things too far.  What we want is to
> be able to replicate the behavior of the branch's last released
> version, using whatever build tools we are currently using.  So
> back-patching something like that is counterproductive, because
> now the behavior is not what was released.
>
> A minimal amount of maintenance would be "only back-patch fixes
> for issues that cause failure-to-build".  The next step up is "fix
> issues that cause failure-to-pass-regression-tests", and then above
> that is "fix developer-facing annoyances, such as compiler warnings
> or unwanted test output, as long as you aren't changing user-facing
> behavior".  I now think that it'd be reasonable to include this
> last group, although I'm pretty sure Peter didn't have that in mind
> in his policy sketch.

Yep, that seems reasonable to me.

I guess the point about user-visible bug fixes is that, as soon as we
start doing that, we don't really want it to be hit-or-miss. We could
make a decision to back-patch all bug fixes or those of a certain
severity or whatever we like back to older branches, and then those
branches would be supported or semi-supported depending on what rule
we adopted, and we could even continue to do releases for them if we
so chose. However, it wouldn't be a great idea to back-patch a
completely arbitrary subset of our fixes into those branches, because
then it sort of gets confusing to understand what the status of that
branch is. I don't know that I'm terribly bothered by the idea that
the behavior of the branch might deviate from the last official
release, because most bug fixes are pretty minor and wouldn't really
affect testing much, but it would be a little annoying to explain to
users that those branches contain an arbitrary subset of newer fixes,
and a little hard for us to understand what is and is not there.

That being said, suppose that a new compiler version comes out and on
that new compiler version, 'make check' crashes on the older branch
due to a missing WhateverGetDatum() call that we rectified in a later,
back-patched commit. I would consider it reasonable to back-patch that
particular bug fix into an unsupported branch to make it testable,
just like we would do for a failure-to-build issue.

-- 
Robert Haas
EDB: http://www.enterprisedb.com