Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.
Date
Msg-id CA+TgmobhnjUjVGoBsm8E4W---dcMfayN0jCbPL=qwF+CF8XkfQ@mail.gmail.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.  (Andres Freund <andres@anarazel.de>)
Responses Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.
List pgsql-hackers
On Fri, Feb 12, 2016 at 6:22 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-02-12 13:16:54 -0500, Tom Lane wrote:
>> Investigation showed that there are a couple of reasons.  One,
>> isolationtester's is-it-waiting query takes an insane amount of
>> time under CLOBBER_CACHE_ALWAYS --- over half a second on my
>> reasonably new server.
>
> I wonder if we shouldn't just expose a 'which pid is process X waiting
> for' API, implemented serverside. That's generally really useful, and
> looks like it's actually going to be less complicated than that
> query... And it's surely going to be faster.

If PID 12000 and PID 13000 hold AccessShareLock on relation foo, and
PID 14000 awaits AccessExclusiveLock on that relation, what does the
function return when 14000 is passed as an argument?

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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: NextXID format change (was Re: exposing pg_controldata and pg_config as functions)
Next
From: Christian Ullrich
Date:
Subject: Re: Crash with old Windows on new CPU