sync process names between ps and pg_stat_activity

Started by Peter Eisentrautover 8 years ago8 messages

peter.eisentraut@2ndquadrant.com

over 8 years ago

1 attachment(s)

The process names shown in pg_stat_activity.backend_type as of PG10 and
the process names used in the ps display are in some cases gratuitously
different, so here is a patch to make them more alike. Of course it
could be debated in some cases which spelling was better.

As an aside, is there a reason why the archiver process is not included
in pg_stat_activity?

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

Attachments:

0001-Sync-process-names-between-ps-and-pg_stat_activity.patchtext/plain; charset=UTF-8; name=0001-Sync-process-names-between-ps-and-pg_stat_activity.patch; x-mac-creator=0; x-mac-type=0Download

From 7b6509d284001af17d3c7c365e9db35d4015ec48 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 31 Aug 2017 15:55:49 -0400
Subject: [PATCH] Sync process names between ps and pg_stat_activity

Remove gratuitous differences in the process names shown in
pg_stat_activity.backend_type and the ps output.
---
 doc/src/sgml/monitoring.sgml        | 12 ++++++------
 src/backend/bootstrap/bootstrap.c   | 10 +++++-----
 src/backend/postmaster/autovacuum.c |  4 ++--
 src/backend/postmaster/pgarch.c     |  2 +-
 src/backend/postmaster/pgstat.c     |  2 +-
 src/backend/postmaster/postmaster.c |  4 ++--
 src/backend/postmaster/syslogger.c  |  2 +-
 7 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 5575c2c837..61456dc12f 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -49,11 +49,11 @@ <title>Standard Unix Tools</title>
 <screen>
 $ ps auxww | grep ^postgres
 postgres  15551  0.0  0.1  57536  7132 pts/0    S    18:02   0:00 postgres -i
-postgres  15554  0.0  0.0  57536  1184 ?        Ss   18:02   0:00 postgres: writer process
-postgres  15555  0.0  0.0  57536   916 ?        Ss   18:02   0:00 postgres: checkpointer process
-postgres  15556  0.0  0.0  57536   916 ?        Ss   18:02   0:00 postgres: wal writer process
-postgres  15557  0.0  0.0  58504  2244 ?        Ss   18:02   0:00 postgres: autovacuum launcher process
-postgres  15558  0.0  0.0  17512  1068 ?        Ss   18:02   0:00 postgres: stats collector process
+postgres  15554  0.0  0.0  57536  1184 ?        Ss   18:02   0:00 postgres: background writer
+postgres  15555  0.0  0.0  57536   916 ?        Ss   18:02   0:00 postgres: checkpointer
+postgres  15556  0.0  0.0  57536   916 ?        Ss   18:02   0:00 postgres: walwriter
+postgres  15557  0.0  0.0  58504  2244 ?        Ss   18:02   0:00 postgres: autovacuum launcher
+postgres  15558  0.0  0.0  17512  1068 ?        Ss   18:02   0:00 postgres: stats collector
 postgres  15582  0.0  0.0  58772  3080 ?        Ss   18:04   0:00 postgres: joe runbug 127.0.0.1 idle
 postgres  15606  0.0  0.0  58772  3052 ?        Ss   18:07   0:00 postgres: tgl regression [local] SELECT waiting
 postgres  15610  0.0  0.0  58772  3056 ?        Ss   18:07   0:00 postgres: tgl regression [local] idle in transaction
@@ -102,7 +102,7 @@ <title>Standard Unix Tools</title>
 (1 row)
 
 $ ps aux|grep server1
-postgres   27093  0.0  0.0  30096  2752 ?        Ss   11:34   0:00 postgres: server1: writer process
+postgres   27093  0.0  0.0  30096  2752 ?        Ss   11:34   0:00 postgres: server1: background writer
 ...
 </screen>
   </para>
diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c
index 0453fd4ac1..2354ce43ae 100644
--- a/src/backend/bootstrap/bootstrap.c
+++ b/src/backend/bootstrap/bootstrap.c
@@ -308,19 +308,19 @@ AuxiliaryProcessMain(int argc, char *argv[])
 		switch (MyAuxProcType)
 		{
 			case StartupProcess:
-				statmsg = "startup process";
+				statmsg = pgstat_get_backend_desc(B_STARTUP);
 				break;
 			case BgWriterProcess:
-				statmsg = "writer process";
+				statmsg = pgstat_get_backend_desc(B_BG_WRITER);
 				break;
 			case CheckpointerProcess:
-				statmsg = "checkpointer process";
+				statmsg = pgstat_get_backend_desc(B_CHECKPOINTER);
 				break;
 			case WalWriterProcess:
-				statmsg = "wal writer process";
+				statmsg = pgstat_get_backend_desc(B_WAL_WRITER);
 				break;
 			case WalReceiverProcess:
-				statmsg = "wal receiver process";
+				statmsg = pgstat_get_backend_desc(B_WAL_RECEIVER);
 				break;
 			default:
 				statmsg = "??? process";
diff --git a/src/backend/postmaster/autovacuum.c b/src/backend/postmaster/autovacuum.c
index 776b1c0a9d..b745d8962e 100644
--- a/src/backend/postmaster/autovacuum.c
+++ b/src/backend/postmaster/autovacuum.c
@@ -436,7 +436,7 @@ AutoVacLauncherMain(int argc, char *argv[])
 	am_autovacuum_launcher = true;
 
 	/* Identify myself via ps */
-	init_ps_display("autovacuum launcher process", "", "", "");
+	init_ps_display(pgstat_get_backend_desc(B_AUTOVAC_LAUNCHER), "", "", "");
 
 	ereport(DEBUG1,
 			(errmsg("autovacuum launcher started")));
@@ -1519,7 +1519,7 @@ AutoVacWorkerMain(int argc, char *argv[])
 	am_autovacuum_worker = true;
 
 	/* Identify myself via ps */
-	init_ps_display("autovacuum worker process", "", "", "");
+	init_ps_display(pgstat_get_backend_desc(B_AUTOVAC_WORKER), "", "", "");
 
 	SetProcessingMode(InitProcessing);
 
diff --git a/src/backend/postmaster/pgarch.c b/src/backend/postmaster/pgarch.c
index ddf9d698e0..1c6cf83f8c 100644
--- a/src/backend/postmaster/pgarch.c
+++ b/src/backend/postmaster/pgarch.c
@@ -236,7 +236,7 @@ PgArchiverMain(int argc, char *argv[])
 	/*
 	 * Identify myself via ps
 	 */
-	init_ps_display("archiver process", "", "", "");
+	init_ps_display("archiver", "", "", "");
 
 	pgarch_MainLoop();
 
diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
index 1f75e2e97d..3ff9bdaf71 100644
--- a/src/backend/postmaster/pgstat.c
+++ b/src/backend/postmaster/pgstat.c
@@ -4213,7 +4213,7 @@ PgstatCollectorMain(int argc, char *argv[])
 	/*
 	 * Identify myself via ps
 	 */
-	init_ps_display("stats collector process", "", "", "");
+	init_ps_display("stats collector", "", "", "");
 
 	/*
 	 * Read in existing stats files or initialize the stats to zero.
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 95180b2ef5..f2c97747f9 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -4259,14 +4259,14 @@ BackendInitialize(Port *port)
 	 *
 	 * For a walsender, the ps display is set in the following form:
 	 *
-	 * postgres: wal sender process <user> <host> <activity>
+	 * postgres: walsender <user> <host> <activity>
 	 *
 	 * To achieve that, we pass "wal sender process" as username and username
 	 * as dbname to init_ps_display(). XXX: should add a new variant of
 	 * init_ps_display() to avoid abusing the parameters like this.
 	 */
 	if (am_walsender)
-		init_ps_display("wal sender process", port->user_name, remote_ps_data,
+		init_ps_display(pgstat_get_backend_desc(B_WAL_SENDER), port->user_name, remote_ps_data,
 						update_process_title ? "authentication" : "");
 	else
 		init_ps_display(port->user_name, port->database_name, remote_ps_data,
diff --git a/src/backend/postmaster/syslogger.c b/src/backend/postmaster/syslogger.c
index 3255b42c7d..aeb117796d 100644
--- a/src/backend/postmaster/syslogger.c
+++ b/src/backend/postmaster/syslogger.c
@@ -173,7 +173,7 @@ SysLoggerMain(int argc, char *argv[])
 
 	am_syslogger = true;
 
-	init_ps_display("logger process", "", "", "");
+	init_ps_display("logger", "", "", "");
 
 	/*
 	 * If we restarted, our stderr is already redirected into our own input

base-commit: b5c75feca7ffb2667c42b86286e262d6cb709b76
-- 
2.14.1

Tom Lane

tgl@sss.pgh.pa.us

over 8 years ago

In reply to: Peter Eisentraut (#1)

Re: sync process names between ps and pg_stat_activity

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

As an aside, is there a reason why the archiver process is not included
in pg_stat_activity?

It's not connected to shared memory.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

MauMau

maumau307@gmail.com

over 8 years ago

In reply to: Peter Eisentraut (#1)

Re: sync process names between ps and pg_stat_activity

From: Peter Eisentraut

The process names shown in pg_stat_activity.backend_type as of PG10

and

the process names used in the ps display are in some cases

gratuitously

different, so here is a patch to make them more alike. Of course it
could be debated in some cases which spelling was better.

(1)
In the following comment, it's better to change "wal sender process"
to "walsender" to follow the modified name.

-     * postgres: wal sender process <user> <host> <activity>
+     * postgres: walsender <user> <host> <activity>
      *
      * To achieve that, we pass "wal sender process" as username and
username
      * as dbname to init_ps_display(). XXX: should add a new variant
of
      * init_ps_display() to avoid abusing the parameters like this.
      */

(2)
"WAL writer process" is used, not "walwriter", is used in postmaster.c
as follows. I guess this is for natural language. Is this intended?
I'm OK with either, though.

HandleChildCrash(pid, exitstatus,
_("WAL writer process"));

case WalWriterProcess:
ereport(LOG,
(errmsg("could not fork WAL writer process:
%m")));

Personally, I prefer "wal writer", "wal sender" and "wal receiver"
that separate words as other process names. But I don't mind leaving
them as they are now. I'd like to make this as ready for committer
when I get some reply.

Regards
MauMau

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut

peter.eisentraut@2ndquadrant.com

over 8 years ago

In reply to: MauMau (#3)

Re: sync process names between ps and pg_stat_activity

On 9/18/17 02:07, MauMau wrote:

(1)
In the following comment, it's better to change "wal sender process"
to "walsender" to follow the modified name.
-     * postgres: wal sender process <user> <host> <activity>
+     * postgres: walsender <user> <host> <activity>
*
* To achieve that, we pass "wal sender process" as username and
username

good catch

(2)
"WAL writer process" is used, not "walwriter", is used in postmaster.c
as follows. I guess this is for natural language. Is this intended?
I'm OK with either, though.

HandleChildCrash(pid, exitstatus,
_("WAL writer process"));

Yes, we usually use that spelling in user-facing messages.

Personally, I prefer "wal writer", "wal sender" and "wal receiver"
that separate words as other process names. But I don't mind leaving
them as they are now.

If we were to change those, that would break existing queries for
pg_stat_activity. That's new in PG10, so we could change it if we were
really eager. But it's probably not worth bothering. Then again, there
is pg_stat_wal_receiver. So it's all totally inconsistent. Not sure
where to go.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tsunakawa, Takayuki

tsunakawa.takay@jp.fujitsu.com

over 8 years ago

In reply to: Peter Eisentraut (#4)

Re: sync process names between ps and pg_stat_activity

From: pgsql-hackers-owner@postgresql.org

[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Peter Eisentraut

Personally, I prefer "wal writer", "wal sender" and "wal receiver"
that separate words as other process names. But I don't mind leaving
them as they are now.

If we were to change those, that would break existing queries for
pg_stat_activity. That's new in PG10, so we could change it if we were
really eager. But it's probably not worth bothering. Then again, there
is pg_stat_wal_receiver. So it's all totally inconsistent. Not sure
where to go.

OK, I'm comfortable with as it is now.

I made this ready for committer. You can fix the following and commit the patch. Thank you.

* To achieve that, we pass "wal sender process" as username and
username

good catch

Regards
Takayuki Tsunakawa

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Michael Paquier

michael.paquier@gmail.com

over 8 years ago

In reply to: Tom Lane (#2)

Re: sync process names between ps and pg_stat_activity

On Fri, Sep 1, 2017 at 5:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

As an aside, is there a reason why the archiver process is not included
in pg_stat_activity?

It's not connected to shared memory.

Do you think that monitoring would be a reason sufficient to do so? My
personal opinion on the matter is that people are more and more going
to move on with pull (*) models (aka pg_receivewal and such with
replication slots) instead of push (*) models (use of
archive_command), so that monitoring of the archiver becomes less and
less useful in the long-term. And there is also pg_stat_archiver that
covers largely the gap for archive failures.

Still, one reason that could be used to connect it to shared memory is
to control the interval of time used for archive attempts, which is
now a interval hardcoded of 1s in pgarch_ArchiverCopyLoop(). Here more
flexibility would be definitely useful.

(*): this wording is from a colleague, not from me.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane

tgl@sss.pgh.pa.us

over 8 years ago

In reply to: Michael Paquier (#6)

Re: sync process names between ps and pg_stat_activity

Michael Paquier <michael.paquier@gmail.com> writes:

On Fri, Sep 1, 2017 at 5:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

As an aside, is there a reason why the archiver process is not included
in pg_stat_activity?

It's not connected to shared memory.

Do you think that monitoring would be a reason sufficient to do so? My
personal opinion on the matter is that people are more and more going
to move on with pull (*) models (aka pg_receivewal and such with
replication slots) instead of push (*) models (use of
archive_command), so that monitoring of the archiver becomes less and
less useful in the long-term. And there is also pg_stat_archiver that
covers largely the gap for archive failures.

Meh. I think keeping it separate from shared memory is a good thing
for reliability reasons.

Still, one reason that could be used to connect it to shared memory is
to control the interval of time used for archive attempts, which is
now a interval hardcoded of 1s in pgarch_ArchiverCopyLoop(). Here more
flexibility would be definitely useful.

AFAIR, GUC reloads work regardless of that. If we wanted to make the
interval configurable, this would not prevent us from doing so.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut

peter.eisentraut@2ndquadrant.com

over 8 years ago

In reply to: Tsunakawa, Takayuki (#5)

Re: sync process names between ps and pg_stat_activity

On 9/19/17 21:30, Tsunakawa, Takayuki wrote:

From: pgsql-hackers-owner@postgresql.org

[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Peter Eisentraut

Personally, I prefer "wal writer", "wal sender" and "wal receiver"
that separate words as other process names. But I don't mind leaving
them as they are now.

If we were to change those, that would break existing queries for
pg_stat_activity. That's new in PG10, so we could change it if we were
really eager. But it's probably not worth bothering. Then again, there
is pg_stat_wal_receiver. So it's all totally inconsistent. Not sure
where to go.

OK, I'm comfortable with as it is now.

I made this ready for committer. You can fix the following and commit the patch. Thank you.

Committed. Thank you.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers