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

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
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