On Fri, Mar 31, 2017 at 7:53 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > So Andres says defer this, but Robert says "more review", which is > more than just deferral. > > We have some risky things in this release such as Hash Indexes, > function changes. I perfectly understand that perception of risk is > affected significantly by whether you wrote something or not. Andres > and Robert did not write it and so they see problems.
While that's probably true, I don't think that's the only thing going on here: 1. Hash indexes were reviewed and reworked repeatedly until nobody could find any more problems, including people like Jesper Pederson who do not work for EDB and who did extensive testing. Similarly with the expression evaluation stuff, which got some review from Heikki and even more from Tom. Now, several people who do not work for 2ndQuadrant have recently started looking at WARM and many of those reviews have found problems and regressions. If we're to hold things to the same standard, those things should be looked into and fixed before there is any talk of committing anything. My concern is that there seems to be (even with the patches already committed) a desire to minimize the importance of the problems that have been found -- which I think is probably because fixing them would take time, and we don't have much time left in this release cycle. We should regard the time between feature freeze and release as a time to fix the things that good review missed, not as a substitute for fixing things that should have (or actually were) found during review prior to commit. 2. WARM is a non-optional feature which touches the on-disk format. There is nothing more dangerous than that. If hash indexes have bugs, people can avoid those bugs by not using them; there are good reasons to suppose that hash indexes have very few existing users. The expression evaluation changes, IMHO, are much more dangerous because everyone will be exposed to them, but they will not likely corrupt your data because they don't touch the on-disk format. WARM is even a little more dangerous than that; everyone is exposed to those bugs, and in the worst case they could eat your data. I agree that WARM could be a pretty great feature, but I think you're underestimating the negative effects that could result from committing it too soon. -- 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
