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: http://www.postgresql.org/mailpref/pgsql-hackers
