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 http://www.postgresql.org/about/donate
