From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "pgsql-patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] 'Waiting on lock' |
Date: | 2007-06-19 17:28:55 |
Message-ID: | 7825.1182274135@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Gregory Stark <stark(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-06-19 17:32:04 | Re: [HACKERS] 'Waiting on lock' |
Previous Message | Tom Lane | 2007-06-19 14:28:29 | Re: WIP: rewrite numeric division |