On Fri, Feb 12, 2016 at 4:59 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers