On Tue, 2007-06-19 at 16:24 -0400, Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
> > * Tom Lane (tgl@sss.pgh.pa.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
