Re: Signaling of waiting for a cleanup lock?
От | Robert Haas |
---|---|
Тема | Re: Signaling of waiting for a cleanup lock? |
Дата | |
Msg-id | CA+TgmoaaaZ==7-zMb79tpf=S8zoHrZsc2=XyLhLiRHzi9KUEVQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Signaling of waiting for a cleanup lock? (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On Mon, Apr 14, 2014 at 10:50 AM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2014-04-14 15:45:45 +0100, Simon Riggs wrote: >> On 13 April 2014 16:44, Andres Freund <andres@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 <andres@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. >> >> pg_stat_activity.waiting = true > > Yes. That's what I suggested above. The patch for it is trivial, but: > Currently - I think - everything that sets waiting = true, also has > contents in pg_locks. Not sure if it will confuse users if that's not > the case anymore. In my personal opinion, it would be OK to change that, provided that we have some real good documentation for it. Longer-term, I'm wondering if we shouldn't have something like pg_stat_activity.wait_type instead of pg_stat_activity.waiting. It could be NULL when not waiting, or otherwise "lock", "lwlock", "buffer cleanup", etc. >> Easy to set the ps message also > > That actually makes it considerably more expensive since we'd need to > save the old string somewhere. I am not sure it will be relevant, but > it's not as easy a sell as just setting a single boolean. Yeah, I'm not too sanguine about squeezing that part into 9.4. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: