Re: isolation check takes a long time
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-07-17T20:28:32Z
Lists: pgsql-hackers
On Tue, Jul 17, 2012 at 01:56:19PM -0400, Alvaro Herrera wrote: > Excerpts from Andrew Dunstan's message of dom jul 15 16:42:22 -0400 2012: > > I'm looking into that. But given that the default is to set > > max_prepared_transactions to 0, shouldn't we just remove that test from the > > normal installcheck schedule? > That's a thought -- AFAIR we do provide a numeric_big test that's not > exercised by the regular regress schedule, for a precedent. It would be nice to have a pattern for adding tests run less often than "every commit" but more often than "whenever a human explicitly remembers the test and invokes it manually". Perhaps a schedule that the recommended buildfarm configuration would somehow run every two weeks and before each release (including betas and branch releases). > However, there's more work to do in isolation testing. It'd be good to > have it being routinely run in serializable isolation level, for > example, not just in read committed. Except for the foreign key specs, isolation test specs request a specific isolation level when starting their transactions. Running such specs under different default_transaction_isolation settings primarily confirms that "BEGIN TRANSACTION ISOLATION LEVEL x" is indistinguishable from "BEGIN" under default_transaction_isolation = x. It might also discover transaction isolation sensitivity in the setup/cleanup steps, which often omit explicit transaction control. I don't think such verification justifies regularly running thousands of tests. The foreign key tests, however, would benefit from running under all three isolation levels. Let's control it per-spec instead of repeating the entire suite.