Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On 9/27/17 18:59, Daniel Gustafsson wrote: > The patch applies with minor fuzz, compiles without introduced warnings and > work the way it says on the tin. The utility of the proposed functionality is > a clear win so +1 on getting that in. I have committed this patch incorporating the feedback

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On 8/31/17 23:22, Michael Paquier wrote: > On Fri, Sep 1, 2017 at 4:49 AM, Peter Eisentraut > wrote: >> On 5/30/17 23:10, Peter Eisentraut wrote: >>> Here is a proposed solution that splits bgw_name into bgw_type and >>> bgw_name_extra. bgw_type shows up in

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

> On 31 Aug 2017, at 21:49, Peter Eisentraut > wrote: > > On 5/30/17 23:10, Peter Eisentraut wrote: >> Here is a proposed solution that splits bgw_name into bgw_type and >> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. >> Uses of

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On 25/09/17 16:45, Peter Eisentraut wrote: > On 8/31/17 23:22, Michael Paquier wrote: >>> One open question is how to treat a missing (empty) bgw_type. I >>> currently fill in bgw_name as a fallback. We could also treat it as an >>> error or a warning as a transition measure. >> >> Hm. Why not

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On 8/31/17 23:22, Michael Paquier wrote: >> One open question is how to treat a missing (empty) bgw_type. I >> currently fill in bgw_name as a fallback. We could also treat it as an >> error or a warning as a transition measure. > > Hm. Why not reporting an empty type string as NULL at SQL

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On Fri, Sep 1, 2017 at 4:49 AM, Peter Eisentraut wrote: > On 5/30/17 23:10, Peter Eisentraut wrote: >> Here is a proposed solution that splits bgw_name into bgw_type and >> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. >> Uses of

bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On 5/30/17 23:10, Peter Eisentraut wrote: > Here is a proposed solution that splits bgw_name into bgw_type and > bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. > Uses of application_name are removed, because they are no longer > necessary to identity the process type.

Re: [HACKERS] Why does logical replication launcher set application_name?

On Tue, Jun 6, 2017 at 10:58 PM, Peter Eisentraut wrote: > The decision was made to add background workers to pg_stat_activity, but > no facility was provided to tell the background workers apart. Is it > now the job of every background worker to invent a hack

Re: [HACKERS] Why does logical replication launcher set application_name?

On Wed, Jun 7, 2017 at 4:58 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 6/6/17 15:58, Robert Haas wrote: > > The problem with the status quo (after Peter's commit) is that there's > > now nothing at all to identify the logical replication launcher, apart > > from the

Re: [HACKERS] Why does logical replication launcher set application_name?

On 6/6/17 15:58, Robert Haas wrote: > The problem with the status quo (after Peter's commit) is that there's > now nothing at all to identify the logical replication launcher, apart > from the wait_event field, which is likely to be LogicalLauncherMain > fairly often if you've got the launcher. I

Re: [HACKERS] Why does logical replication launcher set application_name?

On Sat, Jun 3, 2017 at 3:33 AM, Kuntal Ghosh wrote: >> Agreed with this. >> >> However, I am not sure about the bgw_name_extra. I think I would have >> preferred keeping full bgw_name field which would be used where full >> name is needed and bgw_type where only the

Re: [HACKERS] Why does logical replication launcher set application_name?

On 6/2/17 23:23, Peter Eisentraut wrote: > On 6/2/17 15:08, Peter Eisentraut wrote: >> On 5/30/17 23:10, Peter Eisentraut wrote: >>> Here is a proposed solution that splits bgw_name into bgw_type and >>> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. >>> Uses of

Re: [HACKERS] Why does logical replication launcher set application_name?

On 03/06/17 05:18, Peter Eisentraut wrote: > On 6/2/17 16:44, Petr Jelinek wrote: >> However, I am not sure about the bgw_name_extra. I think I would have >> preferred keeping full bgw_name field which would be used where full >> name is needed and bgw_type where only the worker type is used. The

Re: [HACKERS] Why does logical replication launcher set application_name?

On Sat, Jun 3, 2017 at 4:33 PM, Kuntal Ghosh wrote: > On Sat, Jun 3, 2017 at 2:14 AM, Petr Jelinek > wrote: >> However, I am not sure about the bgw_name_extra. I think I would have >> preferred keeping full bgw_name field which would be

Re: [HACKERS] Why does logical replication launcher set application_name?

On Sat, Jun 3, 2017 at 8:53 AM, Peter Eisentraut wrote: > On 6/2/17 15:08, Peter Eisentraut wrote: >> On 5/30/17 23:10, Peter Eisentraut wrote: >>> Here is a proposed solution that splits bgw_name into bgw_type and >>> bgw_name_extra. bgw_type shows up in

Re: [HACKERS] Why does logical replication launcher set application_name?

On Sat, Jun 3, 2017 at 2:14 AM, Petr Jelinek wrote: > On 02/06/17 21:05, Peter Eisentraut wrote: >> On 6/2/17 02:31, Masahiko Sawada wrote: >>> I'd say current patch makes the user difficult to >>> distinguish between apply worker and table sync worker. >> >> We

Re: [HACKERS] Why does logical replication launcher set application_name?

On 6/2/17 15:08, Peter Eisentraut wrote: > On 5/30/17 23:10, Peter Eisentraut wrote: >> Here is a proposed solution that splits bgw_name into bgw_type and >> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. >> Uses of application_name are removed, because they are no longer >>

Re: [HACKERS] Why does logical replication launcher set application_name?

On 6/2/17 16:44, Petr Jelinek wrote: > However, I am not sure about the bgw_name_extra. I think I would have > preferred keeping full bgw_name field which would be used where full > name is needed and bgw_type where only the worker type is used. The > concatenation just doesn't sit well with me,

Re: [HACKERS] Why does logical replication launcher set application_name?

On 02/06/17 21:05, Peter Eisentraut wrote: > On 6/2/17 02:31, Masahiko Sawada wrote: >> I'd say current patch makes the user difficult to >> distinguish between apply worker and table sync worker. > > We could arguably make apply workers and sync workers have different > bgw_type values. But if

Re: [HACKERS] Why does logical replication launcher set application_name?

On 5/30/17 23:10, Peter Eisentraut wrote: > Here is a proposed solution that splits bgw_name into bgw_type and > bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. > Uses of application_name are removed, because they are no longer > necessary to identity the process type. > >

Re: [HACKERS] Why does logical replication launcher set application_name?

On 6/2/17 02:31, Masahiko Sawada wrote: > On Wed, May 31, 2017 at 12:10 PM, Peter Eisentraut > wrote: >> Here is a proposed solution that splits bgw_name into bgw_type and >> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. >> Uses of

Re: [HACKERS] Why does logical replication launcher set application_name?

On Wed, May 31, 2017 at 12:10 PM, Peter Eisentraut wrote: > Here is a proposed solution that splits bgw_name into bgw_type and > bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. > Uses of application_name are removed, because they are no

Re: [HACKERS] Why does logical replication launcher set application_name?

Here is a proposed solution that splits bgw_name into bgw_type and bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. Uses of application_name are removed, because they are no longer necessary to identity the process type. This code appears to be buggy because I sometimes get

Re: [HACKERS] Why does logical replication launcher set application_name?

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 >

Re: [HACKERS] Why does logical replication launcher set application_name?

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

Re: [HACKERS] Why does logical replication launcher set application_name?

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

Re: [HACKERS] Why does logical replication launcher set application_name?

On 4/18/17 12:37, Tom Lane wrote: > Peter Eisentraut writes: >> I think showing bgw_name as backend_type always sounds reasonable. No >> need to treat external implementations differently. > > That's definitely an approach we could use. It would encourage

Re: [HACKERS] Why does logical replication launcher set application_name?

On 18/04/17 19:18, Tom Lane wrote: > Petr Jelinek writes: >> On 18/04/17 18:24, Peter Eisentraut wrote: >>> I don't see why we need to do that. It is showing the correct >>> information, isn't it? > >> It does, but it's also one of the things Tom complained about

Re: [HACKERS] Why does logical replication launcher set application_name?

Petr Jelinek writes: > On 18/04/17 18:24, Peter Eisentraut wrote: >> I don't see why we need to do that. It is showing the correct >> information, isn't it? > It does, but it's also one of the things Tom complained about and I > think he is right in that at least

Re: [HACKERS] Why does logical replication launcher set application_name?

On 18/04/17 18:24, Peter Eisentraut wrote: > On 4/18/17 12:13, Petr Jelinek wrote: >> We can definitely easily detect that the bgworker is internal one by >> library_name equals 'postgres' so we can easily remove the usesysid and >> usename based on that. > > I don't see why we need to do that.

Re: [HACKERS] Why does logical replication launcher set application_name?

Peter Eisentraut writes: > I think showing bgw_name as backend_type always sounds reasonable. No > need to treat external implementations differently. That's definitely an approach we could use. It would encourage people to use short bgw_names, which is a

Re: [HACKERS] Why does logical replication launcher set application_name?

On 4/18/17 12:13, Petr Jelinek wrote: > We can definitely easily detect that the bgworker is internal one by > library_name equals 'postgres' so we can easily remove the usesysid and > usename based on that. I don't see why we need to do that. It is showing the correct information, isn't it? >

Re: [HACKERS] Why does logical replication launcher set application_name?

On 16/04/17 22:27, Petr Jelinek wrote: > On 16/04/17 18:47, Tom Lane wrote: >> Craig Ringer writes: >>> On 12 April 2017 at 13:34, Kuntal Ghosh wrote: For backend_type=background worker, application_name shows the name of the

Re: [HACKERS] Why does logical replication launcher set application_name?

On 16/04/17 18:47, Tom Lane wrote: > Craig Ringer writes: >> On 12 April 2017 at 13:34, Kuntal Ghosh wrote: >>> For backend_type=background worker, application_name shows the name of >>> the background worker (BackgroundWorker->bgw_name). I

Re: [HACKERS] Why does logical replication launcher set application_name?

Craig Ringer writes: > On 12 April 2017 at 13:34, Kuntal Ghosh wrote: >> For backend_type=background worker, application_name shows the name of >> the background worker (BackgroundWorker->bgw_name). I think we need >> some way to distinguish

Re: [HACKERS] Why does logical replication launcher set application_name?

On 12/04/17 02:32, Robert Haas wrote: > On Tue, Apr 11, 2017 at 8:11 PM, Michael Paquier > wrote: >> On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote: >>> I notice looking at pg_stat_activity that the logical replication launcher >>> sets its

Re: [HACKERS] Why does logical replication launcher set application_name?

On 12 April 2017 at 13:34, Kuntal Ghosh wrote: > For backend_type=background worker, application_name shows the name of > the background worker (BackgroundWorker->bgw_name). I think we need > some way to distinguish among different background workers. But, >

Re: [HACKERS] Why does logical replication launcher set application_name?

On Wed, Apr 12, 2017 at 6:02 AM, Robert Haas wrote: > On Tue, Apr 11, 2017 at 8:11 PM, Michael Paquier > wrote: >> On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote: >>> I notice looking at pg_stat_activity that the logical

Re: [HACKERS] Why does logical replication launcher set application_name?

On Tue, Apr 11, 2017 at 8:11 PM, Michael Paquier wrote: > On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote: >> I notice looking at pg_stat_activity that the logical replication launcher >> sets its application_name to "logical replication launcher".

Re: [HACKERS] Why does logical replication launcher set application_name?

On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote: > I notice looking at pg_stat_activity that the logical replication launcher > sets its application_name to "logical replication launcher". This seems > inconsistent (no other standard background process sets application_name),

[HACKERS] Why does logical replication launcher set application_name?

I notice looking at pg_stat_activity that the logical replication launcher sets its application_name to "logical replication launcher". This seems inconsistent (no other standard background process sets application_name), redundant with other columns that already tell you what it is, and an