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().
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.
regards, tom lane
