On Thu, Dec 17, 2015 at 2:55 AM, Peter Geoghegan <p...@heroku.com> wrote: > On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan <p...@heroku.com> wrote: >>> In any case, at this point 9.5 is really aimed to be stabilized, so >>> targeting only master is a far saner approach IMO for this patch. >>> Pushing that in 9.5 a couple of months back may have given enough >>> reason to do so... But well life is life. >> >> No, this really isn't an optimization at all. > > I should add: I think that the chances of this patch destabilizing the > code are very slim, once it receives the proper review. Certainly, I > foresee no possible downside to not inserting the doomed IndexTuple, > since it's guaranteed to have its heap tuple super-deleted immediately > afterwards. > > That's the only real behavioral change proposed here. So, I would > prefer it if we got this in before the first stable release of 9.5.
No, it's far too late to be pushing this into 9.5. We are at RC1 now and hoping to cut a final release right after Christmas. I think it's quite wrong to argue that these changes have no risk of destabilizing 9.5. Nobody is exempt from having bugs in their code - not me, not you, not Tom Lane. But quite apart from that, there seems to be no compelling benefit to having these changes in 9.5. You say that the branches will diverge needlessly, but the whole point of having branches is that we do need things to diverge. The question isn't "why shouldn't these go into 9.5?" but "do these fix something that is clearly broken in 9.5 and must be fixed to avoid hurting users?". Andres has said clearly that he doesn't think so, and Heikki didn't seem convinced that we wanted the changes at all. I've read over the thread and I think that even if all the good things you say about this patch are 100% true, it doesn't amount to a good reason to back-patch. Code that does something possibly non-sensical or sub-optimal isn't a reason to back-patch in the absence of a clear, user-visible consequence. I think it's a shame that we haven't gotten this patch dealt with just because when somebody submits a patch in June, it's not very nice for it to still be pending in December, but since this stuff is even further outside my area of expertise than the sorting stuff, and since me and my split personalities only have so many hours in the day, I'm going to have to leave it to somebody else to pick up anyhow. But that's a separate issue from whether this should be back-patched. -- 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