On Jan 30, 2007, at 6:32 PM, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> 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                                            [EMAIL PROTECTED]
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to