sync process names between ps and pg_stat_activity
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t37337psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 10:25 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t37337_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t37337_1 && git checkout t37337_1Patchset v1 (message #1) is on t37337_1
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
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
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
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
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
usernamegood 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
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
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
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