On Sun, Apr 13, 2014 at 9:14 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-04-12 17:40:34 -0400, Robert Haas wrote: >> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund <and...@2ndquadrant.com> >> wrote: >> > VACUUM sometimes waits synchronously for a cleanup lock on a heap >> > page. Sometimes for a long time. Without reporting it externally. >> > Rather confusing ;). >> > >> > Since we only take cleanup locks around vacuum, how about we report at >> > least in pgstat that we're waiting? At the moment, there's really no way >> > to know if that's what's happening. >> >> That seems like a pretty good idea to me. > > What I am not sure about is how... It's trivial to set > pg_stat_activity.waiting = true, but without a corresponding description > what the backend is waiting for it's not exactly obvious what's > happening. I think that's better than nothing, but maybe somebody has a > glorious better idea. > > Overwriting parts of the query/activity sounds like it'd be somewhat > expensive ugly. > >> I think we've avoided doing >> this for LWLocks for fear that there might be too much overhead, but >> it's hard for me to imagine a workload where you're waiting for >> cleanup locks often enough for the overhead to matter. > > Hm. I am not sure I see the cost as a very compelling thing here. Sure, > we can't list the acquired lwlocks and such, but it should be cheap > enough to export what lwlock we're waiting for if we're going to > sleep. I think it'd be worthwile making that visible somehow. > But that's a separate issue...
How about having a view like pg_lwlocks similar to pg_locks which can be used to capture and provide the useful information? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
