On Fri, 2007-03-02 at 10:08 -0500, Tom Lane wrote:
> How much testing of this patch's concurrent behavior has been done?
> I'm wondering if any other locking thinkos are in there ...
This version of HOT is being developed from scratch, with as much
feedback from the community as possible. The idea was to build it up
brick by brick, so that each assumption/decision could be challenged as
we go. The idea was to avoid a huge review at the end, which could lead
to a fatal flaw being discovered too late to make the release.
An earlier version had extensive analysis of locking to confirm it
worked, but this current version is aiming for minimal invasiveness. So
this version hasn't had extensive testing - yet. But we learned lots of
lessons along the way and that thinking goes into what we have now -
locking is an area of continual concern.
Intermediate reviews would be very useful, if thats possible.
The right kind of testing is clearly going to be important to getting
HOT right. Back in July, we spent some time building concurrent psql
specifically to allow test cases to be written that referenced multiple
sessions. Even if we don't like that thought for production, it would be
great to be able to have a tool that allowed multi-session test cases to
be written. Experience was that it was much, much easier to get a test
case written in a single script where you could easily read the
statement history.
It would also be very useful to have a version of pgstattuple that
worked with heaps, so test cases can be written that examine the header
fields, info flags etc. It would be useful to be able to specify the
basic behaviour in terms of explicit test cases.
Would those two approaches to test execution be desirable in the
regression tests?
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com