On Fri, Feb 12, 2016 at 4:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Instead, what I propose we do about this is to change isolationtester
>> so that once it's decided that a given step is blocked, it no longer
>> issues the is-it-waiting query for that step; it just assumes that the
>> step should be treated as blocked. So all we need do for "backlogged"
>> steps is check PQisBusy/PQconsumeInput. That both greatly reduces the
>> number of is-it-waiting queries that are needed and avoids any flappy
>> behavior of the answer.
>
> Hmm, that seemed to work fine here, but the buildfarm is not very happy
> with it, and on reflection I guess it's just moving the indeterminacy
> somewhere else. If we check for completion of a given step, and don't
> wait till it's either completed or known blocked, then we have a race
> condition that can change the order in which completions are reported.
>
> The fundamental problem I fear is that isolationtester is designed around
> the assumption that only its own actions (query issuances) change the
> state of the database. Trying to use it to test deadlock detection is
> problematic because deadlock-breaking changes the DB state asynchronously.
>
> I think what we have to do is revert that change and dumb down
> deadlock-hard until it produces stable results even on the CLOBBER
> critters. One thing that'd help is reducing the number of processes
> involved --- AFAICS, testing an 8-way deadlock is not really any more
> interesting than testing, say, 4-way, and that would halve the amount
> of time isolationtester spends figuring out the state.
Maybe we should introduce a way to declare whether a step is expected
to wait or not. I thought about doing that, and the only reason I
didn't is because I couldn't figure out a reasonable syntax. But, in
many respects, that would actually be better than the current system
of having isolationtester try to figure it out itself.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company