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 <alvhe...@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to