On Wed, Mar 22, 2017 at 12:20 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Mar 22, 2017 at 1:31 AM, Michael Paquier > <michael.paqu...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers