On Mon, Feb 8, 2016 at 2:36 PM, Joshua D. Drake <j...@commandprompt.com> wrote: > I have no problem running any test cases you wish on a branch in a loop for > the next week and reporting back any errors. > > Where this gets tricky is the tooling itself. For me to be able to do so > (and others really) I need to be able to do this: > > * Download (preferably a tarball but I can do a git pull) > * Exact instructions on how to set up the tests > * Exact instructions on how to run the tests > * Exact instructions on how to report the tests > > If anyone takes the time to do that, I will take the time and resources to > run them.
Well, what I've done is push into the buildfarm code that will allow us to do *the most exhaustive* testing that I know how to do in an automated fashion. Which is to create a file that says this: force_parallel_mode=regress max_parallel_degree=2 And then run this: make check-world TEMP_CONFIG=/path/to/aforementioned/file Now, that is not going to find bugs in the deadlock.c portion of the group locking patch, but it's been wildly successful in finding bugs in other parts of the parallelism code, and there might well be a few more that we haven't found yet, which is why I'm hoping that we'll get this procedure running regularly either on all buildfarm machines, or on some subset of them, or on new animals that just do this. Testing the deadlock.c changes is harder. I don't know of a good way to do it in an automated fashion, which is why I also posted the test code Amit devised which allows construction of manual test cases. Constructing a manual test case is *hard* but doable. I think it would be good to automate this and if somebody's got a good idea about how to fuzz test it I think that would be *great*. But that's not easy to do. We haven't had any testing at all of the deadlock detector up until now, but somehow the deadlock detector itself has been in the tree for a very long time... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers