Hi, On 2018-01-25 17:34:15 -0300, Alvaro Herrera wrote: > Tom Lane wrote: > > Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > > > > I think we could solve this by putting in the same parallel group only > > > slow tests that mostly sleeps, ie. nothing that would monopolize CPU for > > > long enough to cause a problem. Concretely: > > > test: timeouts tuplelock-update deadlock-hard deadlock-soft-2 > > > > OK, but there'd better be a comment there explaining the concern > > very precisely, or somebody will break it. > > Here's a concrete proposal. Runtime is 45.7 seconds on my laptop. It > can be further reduced, but not by more than a second or two unless you > get in the business of modifying other tests. (I only modified > deadlock-soft-2 because it saves 5 seconds).
I'm working an updated version of this. Adding the new tests is a bit painful because of conflicting names making it harder than necessary to schedule tests. While it's possible to work out a schedule that doesn't conflict, it's pretty annoying to do and more importantly seems fragile - it's very easy to create schedules that succeed on one machine, and not on another, based on how slow which tests are. I'm more inclined to be a bit more aggressive in renaming tables - there's not much point in having a lot of "foo"s around. So I'm inclined to rename some of the names that are more likely to conflict. If we agree on doing that, I'd like to do that first, and commit that more aggressively than the schedule itself. An alternative approach would be to have isolationtester automatically create a schema with the specfile's name, and place it in the search path. But that'd make it impossible to use isolationtester against a standby - which I think we currently don't do, but which probably would be a good idea. With regard to the schedule, I'm inclined to order it so that faster test groups are earlier on, just to make it more likely to reach the tests one is debugging faster. Does that sound sane? Do we want to maintain a serial version of the schedule too? I'm wondering if we should just generate both the isolationtester and plain regression test schedule by either adding an option to pg_regress that serializes test groups, or by generating the serial schedule file in a few lines of perl. Greetings, Andres Freund
