On Wed, Jan 11, 2017 at 11:09 PM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > I think as a developer of the patch, what I would like to know is what can > we do address concerns raised by you? What kind of tests you would like to > do to get confidence in the patch?
Well, off the top of my head, I'd say that there are basically four things that can be done to improve the quality of patches. These things are, of course, not a secret: 1. Detailed manual testing. 2. Stress testing. 3. Regression testing (pg_regress, isolation, TAP) perhaps driven by code coverage reports. 4. Detailed code review by highly-qualified individuals. For a patch of this type, I highly recommend stress testing. Amit and his colleagues have done a huge amount of stress testing of the hash index patches and that's turned up quite a few bugs; sometimes the tests had to run for many hours before any failure was provoked. But my real point here is not that reviewing or testing the WARM patch is any different or more difficult than for any other patch. Rather, the issue is that the stakes are higher. Whatever a committer would do (or ask to have done) for a patch of ordinary consequence should be done ten times over for that one, not because it's more likely to have bugs but because any bugs that it does have will hurt more. There's a time for committing and moving on and a time for extreme paranoia. IMHO, this is the latter. -- 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
