Re: [HACKERS] 'Waiting on lock'

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

In response to

Browse pgsql-patches by date

  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