On Tue, 2007-06-19 at 16:24 -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > * Tom Lane ([EMAIL PROTECTED]) 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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to