From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: isolation check takes a long time |
Date: | 2012-07-17 20:28:32 |
Message-ID: | 20120717202832.GB11508@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-07-17 20:59:49 | Re: BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2) |
Previous Message | Jeff Davis | 2012-07-17 18:55:55 | Re: Using pg_upgrade on log-shipping standby servers |