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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster