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

From Peter Eisentraut
Subject Re: [HACKERS] Why does logical replication launcher setapplication_name?
Date
Msg-id 35251f7d-dac2-35a4-18c6-cc7d09064ec7@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Why does logical replication launcher setapplication_name?  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] Why does logical replication launcher set application_name?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Why does logical replication launcher setapplication_name?  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
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?

> But that does not solve the issue of identifying
> the processes in pg_stat_activity as logical replication laucher/worker.
> I wonder if it would be okay to set backend_type to bgw_name for
> internal workers and just leave the external ones as it is (or solve
> them in v11 with some proper API) as we can control the length of name
> there (it will still be longer than the values for other things but
> maybe not too much).

I think showing bgw_name as backend_type always sounds reasonable.  No
need to treat external implementations differently.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] scram and \password
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Logical replication launcher useswal_retrieve_retry_interval