|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, "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.|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> Robert Haas <robertmhaas(at)gmail(dot)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.
regards, tom lane
|Next Message||Andres Freund||2016-02-22 06:55:03||pgsql: Fix wrong keysize in PrivateRefCountHash creation.|
|Previous Message||Tom Lane||2016-02-21 20:23:22||pgsql: Docs: make prose discussion match the ordering of Table 9-58.|
|Next Message||Christoph Berg||2016-02-21 21:42:20||Re: Add generate_series(date,date) and generate_series(date,date,integer)|
|Previous Message||Thom Brown||2016-02-21 20:40:08||Re: Proposal: "Causal reads" mode for load balancing reads without stale data|