From: | Jim Nasby <decibel(at)decibel(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Logging Lock Waits |
Date: | 2007-02-02 05:20:36 |
Message-ID: | C0EB9B91-94E9-492A-A1D8-3D299FD4EECE@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jan 30, 2007, at 6:32 PM, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2007-02-02 05:33:22 | Re: PL/pgSQL RENAME functionality in TODOs |
Previous Message | David Fetter | 2007-02-02 05:11:42 | Re: writing new regexp functions |