From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution. |
Date: | 2016-02-12 22:47:43 |
Message-ID: | CA+Tgmoa_1NV8+DJB6qLF-8Po+RqvE8F4YEeuTXH9MM5OBf9juQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Fri, Feb 12, 2016 at 4:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-02-12 22:49:04 | Re: pgsql: Add missing "static" qualifier. |
Previous Message | Joe Conway | 2016-02-12 22:24:27 | pgsql: Change delimiter used for display of NextXID |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-02-12 22:54:11 | Re: NextXID format change (was Re: exposing pg_controldata and pg_config as functions) |
Previous Message | Joe Conway | 2016-02-12 22:25:34 | Re: NextXID format change (was Re: exposing pg_controldata and pg_config as functions) |