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
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.
In response to
pgsql-patches by date
|Next:||From: Stephen Frost||Date: 2007-06-19 22:29:22|
|Subject: Re: [HACKERS] 'Waiting on lock'|
|Previous:||From: Tom Lane||Date: 2007-06-19 20:24:43|
|Subject: Re: [HACKERS] 'Waiting on lock' |