|From:||Bruce Momjian <bruce(at)momjian(dot)us>|
|To:||Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>|
|Subject:||Re: Lock Wait Statistics (next commitfest)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
What happened to this patch?
Mark Kirkwood wrote:
> Where I work they make extensive use of Postgresql. One of the things
> they typically want to know about are lock waits. Out of the box in
> there is not much in the way of tracking for such, particularly in older
> versions. The view pg_stats is fine for stuff happening *now*, but
> typically I find I'm being asked about something that happened last
> Now for those platforms with dtrace there is a lock wait probe, useful -
> but not for those of us on Linux! There is the conf option to log lock
> waits > deadlock timeout (8.3 onwards), and this is great, but I
> wondered if having something like this available as part of the stats
> module would be useful.
> So here is my initial attempt at this, at this point merely to spark
> discussion (attached patch)
> I have followed some of the ideas from the function execution stats, but
> locks required some special treatment.
> - new parameter track_locks (maybe should be track_lock_waits?)
> - new hash locks attached to stats dbentry
> - several new stat*lock c functions
> - new view pg_stat_lock_waits
> - new attributes for pg_stat_database
> This version has simply exposed the locktag structure in the view along
> with corresponding #waits and wait time. This should probably get
> reformed to look a little more like pg_locks. I figured this is easily
> doable along with the no doubt many changes coming from revew comments.
> Also I did not do any clever amalgamation of transaction lock waits -
> there is probably gonna be a lot of those and keeping the detail is
> unlikely to be useful. It would be easy to collect them all together in
> one transaction entry.
[ application/x-gzip is not supported, skipping... ]
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +
|Next Message||Tom Lane||2010-02-27 03:18:25||Re: Testing of parallel restore with current snapshot|
|Previous Message||Bruce Momjian||2010-02-27 03:12:38||Re: plpgsql: numeric assignment to an integer variable errors out|