Re: Logging Lock Waits

On Jan 30, 2007, at 6:32 PM, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
>> I'm thinking to write an INFO message, so that people can choose  
>> to log
>> this and/or the SQL statement if they choose.
>> e.g. INFO: lock wait time of XXX secs has been exceeded
>
> The available timer resources are already overloaded; adding an
> independent timeout for this will complicate the code more than seems
> justified.  Perhaps you could add a LOG message whenever the
> deadlock-check code runs (and doesn't detect an error, so is about  
> to go
> back to sleep).  This would take almost no effort, and the granularity
> could still be adjusted via the deadlock check timeout.

Sybase collected performance information for a server by periodically  
checking the status of all backend processes (ie: waiting on a user  
lock, waiting on IO, internal lock, etc) and keeping counters. Having  
that information available was useful for debugging performance  
issues (unfortunately I can't provide any specific examples since it  
was years ago I played with it). I'm thinking backends could set  
flags in shared memory to indicate what they're doing and a process  
could poll that every X milliseconds and keep stats on what's going on.

But maybe that's more along the lines of the rewrite of the stats  
system that's been talked about...
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)