Skip site navigation (1) Skip section navigation (2)

Re: Logging Lock Waits

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: (view raw or whole 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      512.569.9461 (cell)

In response to

pgsql-hackers by date

Next:From: Jim NasbyDate: 2007-02-02 05:33:22
Subject: Re: PL/pgSQL RENAME functionality in TODOs
Previous:From: David FetterDate: 2007-02-02 05:11:42
Subject: Re: writing new regexp functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group