Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches) |
Дата | |
Msg-id | CAB7nPqQje-=SW3DudGhUWJNXLqsBDXN2APbXR_1+phmZBXnXPw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches) (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Thu, Mar 23, 2017 at 1:24 AM, Robert Haas <robertmhaas@gmail.com> wrote: > I mean, your argument boils down to "somebody might want to > deliberately hide things from pg_stat_activity". But that's not > really a mode we support in general, and supporting it only for > certain cases doesn't seem like something that this patch should be > about. We could add an option to BackgroundWorkerInitializeConnection > and BackgroundWorkerInitializeConnectionByOid to suppress it, if it's > something that somebody wants, but actually I'd be more inclined to > think that everybody (who has a shared memory connection) should go > into the machinery and then security-filtering should be left to some > higher-level facility that can make policy decisions rather than being > hard-coded in the individual modules. > > But I'm slightly confused as to how this even arises. Background > workers already show up in pg_stat_activity output, or at least I sure > think they do. So why does this patch need to make any change to that > case at all? When working on a couple of bgworkers some time ago, I recalled that they only showed up in pg_stat_activity only if calling pgstat_report_activity() in them. Just looking again, visibly I was mistaken, they do indeed show up when if WaitLatch() or pgstat_report_activity() are not used. Please let me discard that remark. -- Michael
В списке pgsql-hackers по дате отправления: