On Wed, Dec 9, 2015 at 8:23 PM, Noah Misch <n...@leadboat.com> wrote: > 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?
Well, suppose I wanted to know what bugs were fixed between 9.5beta and 9.5.0, for example. I mean, I'm going to run git log src/backend/access/transam/multixact.c ... and the existing commits are going to be there. > 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. Maybe. But I think we could use a little more vigorous discussion of that issue, since Andres doesn't seem to be very convinced by your analysis, and I don't currently understand what you've fixed because I can't, as mentioned several times, follow your patch stack. >> 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? I don't know have anything to add to what others have said in response to this point, except this: the whole point of using a source code management system is to tell you what changed and when. What you are proposing to do makes it unusable for that purpose. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
