Re: Rework the way multixact truncations work

On Wed, Dec 09, 2015 at 11:08:32AM -0500, Robert Haas wrote:
> On Wed, Dec 9, 2015 at 9:43 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > I hope those who have not already read commit 4f627f8 will not waste time
> > reading it. They should instead ignore multixact changes from commit 4f627f8
> > through its revert. The 2015-09-26 commits have not appeared in a supported
> > release, and no other work has built upon them. They have no tenure. (I am
> > glad you talked the author out of back-patching; otherwise, 9.4.5 and 9.3.10
> > would have introduced a data loss bug.) Nobody reported a single defect
> > before my review overturned half the patch. A revert will indeed impose on
> > those who invested time to understand commit 4f627f8, but the silence about
> > its defects suggests the people understanding it number either zero or one.
> > Even as its author and reviewers, you would do better to set aside what you
> > thought you knew about this code.
>
> I just don't find this a realistic model of how people use the git
> log. Maybe you use it this way; I don't. I don't *want* git blame to
> make it seem as if 4f627f8 is not part of the history. For better or
> worse, it is.

I would like to understand how you use git, then. What's one of your models
of using "git log" and/or "git blame" in which you foresee the revert making
history less clear, not more clear?

By the way, it occurs to me that I should also make pg_upgrade blacklist the
range of catversions that might have data loss. No sense in putting ourselves
in the position of asking whether data files of a 9.9.3 cluster spent time in
a 9.5beta2 cluster.

> Ripping it out and replacing it monolithically will not
> change that; it will only make the detailed history harder to
> reconstruct, and I *will* want to reconstruct it.

What's something that might happen six months from now and lead you to inspect
master or 9.5 multixact.c between 4f627f8 and its revert?