Thread: [HACKERS] sync process names between ps and pg_stat_activity
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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
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
usernameand
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 > > 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
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