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

From Tom Lane
Subject Re: [HACKERS] Why does logical replication launcher set application_name?
Date
Msg-id 26804.1492361236@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Why does logical replication launcher set application_name?  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] Why does logical replication launcher setapplication_name?  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
Craig Ringer <craig@2ndquadrant.com> writes:
> On 12 April 2017 at 13:34, Kuntal Ghosh <kuntalghosh.2007@gmail.com> 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,
>> application_name may not be the correct field to show the information.

> It's better than (ab)using 'query' IMO.

> I'd rather an abbreviated entry to address Tom's concerns about
> format. 'lrlaunch' or whatever.

Basically the problem I've got with the LR launcher is that it looks
utterly unlike any other background process in pg_stat_activity.
Leaving out all-null columns to make my point:

regression=# select pid,usesysid,usename,application_name,backend_start,wait_event_type,wait_event,backend_type from
pg_stat_activitywhere application_name != 'psql'; pid  | usesysid | usename  |       application_name       |
backend_start        | wait_event_type |     wait_event      |    backend_type      

-------+----------+----------+------------------------------+-------------------------------+-----------------+---------------------+---------------------25416
|         |          |                              | 2017-04-16 12:32:46.987076-04 | Activity        | AutoVacuumMain
   | autovacuum launcher25418 |       10 | postgres | logical replication launcher | 2017-04-16 12:32:46.988859-04 |
Activity       | LogicalLauncherMain | background worker25414 |          |          |                              |
2017-04-1612:32:46.986745-04 | Activity        | BgWriterHibernate   | background writer25413 |          |          |
                          | 2017-04-16 12:32:46.986885-04 | Activity        | CheckpointerMain    | checkpointer25415 |
        |          |                              | 2017-04-16 12:32:46.9871-04   | Activity        | WalWriterMain
 | walwriter 
(5 rows)

Why has it got non-null entries for usesysid and usename, never mind
application_name?  Why does it not follow the well-established convention
that backend_type is what identifies background processes?

I'm sure the answer to those questions is "it's an implementation artifact
from using the generic bgworker infrastructure", but that does not make it
look any less like sloppy, half-finished work.

If it is a limitation of the bgworker infrastructure that we can't make
the LR processes look more like the other kinds of built-in processes,
then I think we need to fix that limitation.  And I further assert that
we need to do it for v10, because once we ship v10 people will adjust
their tools for this bogus output, and we'll face complaints about
backwards compatibility if we fix it later.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Inadequate parallel-safety check for SubPlans
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] Variable substitution in psql backtick expansion