Re: [HACKERS] 'Waiting on lock' - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] 'Waiting on lock'
Date
Msg-id 7825.1182274135@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] 'Waiting on lock'  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-patches
Gregory Stark <stark@enterprisedb.com> writes:
> Ok, I understand now that early deadlock detection only kicks in when doing
> something like LOCK TABLE and even then only if you're deadlocking because
> you're upgrading a lock. So this works as intended though it's much less
> useful than I thought.

Yeah, that path is not really intended as an optimization, it's just the
simplest way to clean up correctly at that point, per the comment.  The
part of the whole business that actually *is* useful is where we decide
we should grant ourselves the lock immediately --- if we eliminated that
whole loop and just always queued at the end of the list, we'd still get
the lock, but not till after the deadlock check delay had elapsed.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP: rewrite numeric division
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] 'Waiting on lock'