On Mon, Feb 22, 2016 at 2:56 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
