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)
