On Fri, Aug 14, 2015 at 2:57 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> 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).
After some study, I think the best thing to do here is change the way
we handle the case where we reach a step that the use of a connection
that is currently blocked on a lock. Right now, we handle that by
declaring the permutation invalid; I'd like to change that so that
consider that a cue to wait for that connnection to unblock itself.
This will require a number of tests that currently blindly run through
all permutations to specify a list of permutations, or they will hang.
But I'm not sure that's such a bad thing, because running through all
permutations in those cases provides no additional test coverage.
Each invalid permutation runs the sequence of steps only up until the
point where it chooses an invalid next step. Therefore, each invalid
permutation is testing an initial prefix of the steps tested by some
valid permutation. If the "invalid" permutation ceased to be invalid,
because the command at which we give up returned immediately rather
than waiting, that would also change the test output of the other,
valid test of which it is the initial prefix. And therefore, at least
as it seems to me, testing the invalid permutations is just a waste of
CPU time, and we'd be better off not doing it.
Actually, I'm really rather wondering if the list of valid
permutations should also be pruned for some of these tests. Some of
these output files are thousands of lines long, and I'm not sure that
somebody has really gone through that whole file and made sure that
the output of each permutation is expected. And I'm sure some of them
are functionally identical.
Attached are three patches. The first one modifies the isolation
tester to allow multiple sessions to wait, using the design described
above. The second one adds permutation specifications to all of the
existing regression tests that have "invalid" permutations in them, so
that we don't waste time trying those permutations. The third one
adds a couple of simple deadlock tests. I'd like to add tests for
some more complicated scenarios involving soft deadlocks of various
kinds, but this gives you the idea of what I have in mind.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company