On Tue, May 23, 2017 at 07:50:34PM +0200, Petr Jelinek wrote:
> On 20/04/17 21:33, Peter Eisentraut wrote:
> > On 4/18/17 13:18, Tom Lane wrote:
> >> I think you're thinking about it wrong. To my mind the issue is that
> >> there should be some generic way to determine that a bgworker process
> >> is or is not laboring on behalf of an identifiable user. It's great
> >> that we can tell which user it is when there is one, but clearly some
> >> bgworkers will be providing general services that aren't associated with
> >> a single user. So it should be possible to set the userID to zero or
> >> some such when the bgworker is one that isn't associated with a
> >> particular user. Maybe the owning user needs to become an additional
> >> parameter passed in struct BackgroundWorker.
> >
> > I think this is probably a problem particular to the logical replication
> > launcher. Other background workers either do work as a particular user,
> > as you say, or don't touch the database at all. So a localized hack or
> > a simple hide-the-user flag might suffice for now.
> >
>
> But that still leaves the application_name issue. My proposal in general
> would be to add boolean that indicates that the worker is not using
> specific user (this can be easily set in
> InitializeSessionUserIdStandalone()) and will work for multiple things.
>
> About application_name, perhaps we should just add bgw_type or bgw_group
> and show it as worker_type in activity and that's it?
>
> I think this should be open item btw so I'll add it.
[Action required within three days. This is a generic notification.]
The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.
[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
