Re: [HACKERS] Why does logical replication launcher setapplication_name? - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: [HACKERS] Why does logical replication launcher setapplication_name?
Date
Msg-id c9aa21b6-0f20-8e3e-adc0-070c77921bd9@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Why does logical replication launcher setapplication_name?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] Why does logical replication launcher set application_name?  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
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.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] walsender & parallelism
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] walsender & parallelism