Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] 'Waiting on lock'

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>,"pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] 'Waiting on lock'
Date: 2007-06-19 21:34:52
Message-ID: 1182288893.6855.369.camel@silverbirch.site (view raw or flat)
Thread:
Lists: pgsql-patches
On Tue, 2007-06-19 at 16:24 -0400, Tom Lane wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >> In fact, I am scandalized to see that someone has inserted a boatload
> >> of elog calls into CheckDeadLock since 8.2 --- that seems entirely
> >> unsafe.  [ checks revision history... ]
> 
> > Attached is a patch which moves the messages to ProcSleep().

Thanks Greg for taking this on; it would still be in my queue now if you
hadn't, so much appreciated.

> Applied with some further revisions to improve the usefulness of the log
> messages.  There's now one issued when the deadlock timeout elapses, and
> another when the lock is finally obtained:
> 
> LOG:  process 14945 still waiting for AccessExclusiveLock on relation 86076 of database 86042 after 1003.354 ms
> ...
> LOG:  process 14945 acquired AccessExclusiveLock on relation 86076 of database 86042 after 5918.002 ms
> 
> although I just realized that the wording of the second one is
> misleading; it actually comes out when the lock wait ends, whether we
> acquired the lock or not.  (The other possibility is that our statement
> was aborted, eg by SIGINT or statement_timeout.)
> 
> Is it worth having two messages for the two cases?  I'm tempted to just
> not log anything if the statement is aborted --- the cause of the abort
> should be reflected in some later error message, and reporting how long
> we waited before giving up seems not within the charter of
> log_lock_waits.

Sounds good; thanks Tom.


related TODO items:
- add a WAIT n clause in same SQL locations as NOWAIT
- add a lock_wait_timeout (USERSET), default = 0 (unlimited waiting)

to provide better control over lock waits.

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com



In response to

Responses

pgsql-patches by date

Next:From: Stephen FrostDate: 2007-06-19 22:29:22
Subject: Re: [HACKERS] 'Waiting on lock'
Previous:From: Tom LaneDate: 2007-06-19 20:24:43
Subject: Re: [HACKERS] 'Waiting on lock'

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group