On Wed, Dec 09, 2015 at 11:08:32AM -0500, Robert Haas wrote: > On Wed, Dec 9, 2015 at 9:43 AM, Noah Misch <n...@leadboat.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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
