On Mon, Feb 8, 2016 at 2:36 PM, Joshua D. Drake <jd@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