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:

Reply via email to