From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: isolation check takes a long time |
Date: | 2012-07-17 17:56:19 |
Message-ID: | 1342547503-sup-9993@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
>
> We could provide an alternative schedule that does include it.
That's a thought -- AFAIR we do provide a numeric_big test that's not
exercised by the regular regress schedule, for a precedent.
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. I wouldn't want to overload the
slowest machines in the buildfarm (some of which are already barely
capable of running the tests on all branches in a 24h schedule, of which
Stefan Kaltenbrunner is so proud), but if we could have a few of the
fastest members running isolation and isolation-serializable, with
max_prepared_transactions set to a nonzero value, that'd be great.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2012-07-17 17:58:38 | Re: several problems in pg_receivexlog |
Previous Message | Tom Lane | 2012-07-17 17:38:44 | Re: b-tree index search algorithms |