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

On Mon, Feb 22, 2016 at 2:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> As for the patch itself, I'm having trouble grokking what it's trying
>>> to do.  I think it might be worth having a comment defining precisely
>>> what we mean by "A blocks B".  I would define "A blocks B" in general
>>> as either A holds a lock which conflicts with one sought by B
>>> (hard-blocked) or A awaits a lock which conflicts with one sought by B
>>> and precedes it in the wait queue (soft-blocked).
>
>> Yes, that is exactly what I implemented ... and it's something you can't
>> find out from pg_locks.  I'm not sure how that view could be made to
>> expose wait-queue ordering.
>
> Here's an updated version of this patch, now with user-facing docs.
>
> I decided that "pg_blocking_pids()" is a better function name than
> "pg_blocker_pids()".  The code's otherwise the same, although I
> revisited some of the comments.
>
> I also changed quite a few references to "transaction" into "process"
> in the discussion of pg_locks.  The previous choice to conflate
> processes with transactions was never terribly wise in my view, and
> it's certainly completely broken by parallel query.

!    held by the indicated process.  False indicates that this process is
!    currently waiting to acquire this lock, which implies that at
least one other
!    process is holding a conflicting lock mode on the same lockable object.

I know you're just updating existing language here, but this is false.
It only implies that one other process is holding *or waiting for* a
conflicting lock mode on the same lockable object.  Other than that, I
think the documentation changes look good.

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