Re: why can the isolation tester handle only one waiting process?

On Sat, Aug 15, 2015 at 1:17 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
>> 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.
>
> Well, hanging forever may not be all that great. Buildfarm animals with
> test processes stuck probably won't be happy. Maybe put a cap on the
> time we're willing to wait; something like a minute should suffice for
> all reasonable tests.

Good idea. Here's an updated patch series that takes that approach.
It cancels any query after 60 seconds of waiting, and if the query
doesn't respond to the cancel, then it bails out completely after 75
seconds (i.e. 15 seconds after attempting the cancel).

> At the same time I wonder if iterating as quickly
> as possible is really such a hot idea; why don't we sleep even 100ms if
> nothing is to be done immediately? That would reduce log traffic if you
> have log_statements=all, for one thing ...

We could certainly do that; I'm not sure it really matters, though.
We'd probably make the test runtime a bit longer in exchange for a bit
less log chatter. I'm not that excited about it either way.

> I guess (from a patch author perspective) we can just use
> isolationtester -n to produce appropriate permutation lines when
> developing a spec file, and then prune the ones causing trouble.

Yes. And honestly, if you're not going to go through and look at what
happens in all the permutations, then why bother adding the test
anyway? At that point you're just testing that nothing ever changes,
not that anything was correct.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company