On Fri, Aug 14, 2015 at 10:14 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> I had the idea that it would be useful to have some regression tests
>> that verify that the deadlock checker works as advertised, because we
>> currently have just about zero test coverage for it. And it's easy
>> enough to write a regression test that causes a simple 2-way deadlock.
>> But you can't test anything more interesting than that, because of
>> this limitation described in the README:
>>
>> > Currently, at most one step can be waiting at a time. As long as one
>> > step is waiting, subsequent steps are run to completion synchronously.
>>
>> Is there any reason not to try to lift that restriction? (And do we
>> think it's hard?)
>
> It's just what we needed at the time, so we didn't press any further.
> Feel free to lift the restriction if you're so inclined.
Thanks for the reply. It appears that this is to some degree a
semantically relevant restriction. We assume that a step never
unblocks except when we run a future step, which is false in the case
of the deadlock detector. However, once one step is waiting, we run
further steps to completion, which means that there's time for the
deadlock detector to kick in after all. To make this useful for
deadlock testing, something further is needed.
The simplest thing to do seems to be to allow for a way to configure
the maximum number of processes that are expected to wait during a
particular test. That could default to 1, the current behavior.
That's pretty coarse-grained, but I think it would be sufficient for
what I want to do. Alternatively, we could try to provide a way to
attach information to the step, or within the permutation, indicating
the points at which we expect waiters to accumulate and to be
released. I'm not sure exactly what that would look like, though.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
