Robert Haas wrote:
> 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.
Hmm, clearly you couldn't attach the info to the step itself, because a
step that blocks in one permutation doesn't necessarily block in every
permutation. You could attach it to each step that needed it in the
permutation, but then it wouldn't work to leave permutation
specification out for such a test. Maybe that's an acceptable
restriction if you cause the test to fail with a specific error instead
of stalling forever (which is what happens currently IIRC).
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
