Re: exposing wait events for non-backends (was: Tracking wait event for latches)

On Wed, Mar 22, 2017 at 12:20 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Mar 22, 2017 at 1:31 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> Okay, switched as ready for committer. One note for the committer
>> though: keeping the calls of pgstat_bestart() out of
>> BackgroundWorkerInitializeConnection() and
>> BackgroundWorkerInitializeConnectionByOid() keeps users the
>> possibility to not have backends connected to the database show up in
>> pg_stat_activity. This may matter for some users (cloud deployment for
>> example). I am as well in favor in keeping the work of those routines
>> minimal, without touching at pgstat.
>
> I think that's just inviting bugs of omission, in both core and
> extension code. I think it'd be much better to do this in a
> centralized place.

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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company