BUG #13620: Streaming replication process titles should use zero padding for TX ids.

On Tue, Sep 15, 2015 at 3:42 AM, wrote:

From the last 2 lines I would guess at first glance that those processes are

streaming segment "78" at the moment, while they really are at segment "07".
It should be trivial to zero-pad this id.

If you can run ps as an OS user, surely you can query the master
instance for the same information, like that for example:
=# SELECT pg_current_xlog_location(),
pg_xlogfile_name(pg_current_xlog_location());
pg_current_xlog_location | pg_xlogfile_name
--------------------------+--------------------------
0/3000888 | 000000010000000000000003
(1 row)
=# SELECT write_location, pg_xlogfile_name(write_location) FROM
pg_stat_replication;
write_location | pg_xlogfile_name
----------------+--------------------------
0/3000888 | 000000010000000000000003
(1 row)
(ps displays the write location for WAL receiver processes)

Note that this is not a bug, this question is more adapted to
pgsql-general for example.
--
Michael

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

On 2015-09-15 22:18, Michael Paquier wrote:

On Tue, Sep 15, 2015 at 3:42 AM, wrote:

From the last 2 lines I would guess at first glance that those processes are

streaming segment "78" at the moment, while they really are at segment "07".
It should be trivial to zero-pad this id.

If you can run ps as an OS user, surely you can query the master
instance for the same information, like that for example:
=# SELECT pg_current_xlog_location(),
pg_xlogfile_name(pg_current_xlog_location());
pg_current_xlog_location | pg_xlogfile_name
--------------------------+--------------------------
0/3000888 | 000000010000000000000003
(1 row)
=# SELECT write_location, pg_xlogfile_name(write_location) FROM
pg_stat_replication;
write_location | pg_xlogfile_name
----------------+--------------------------
0/3000888 | 000000010000000000000003
(1 row)
(ps displays the write location for WAL receiver processes)

Note that this is not a bug, this question is more adapted to
pgsql-general for example.

Hello,

I understand this is not a bug in the sense that it displays wrong
information, nor that I cannot get the information in a different way.
The problem is that the proctitle functionality, which is very
convenient and much faster than typing the SELECT above, is diminished
by easily misleading people when it displays this id in hex encoding
without zero padding.

To monitor progress I found people tend to only look at the first 2
digits without counting the length. Colleague were tripped up by this
independently already, and I really think zero padding would be useful
there. For the non-experts in the ops team using ps is much more easy
and natural too. If you don't agree just drop the issue.

-Jürgen

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

On Tue, Sep 15, 2015 at 2:27 PM, Jürgen Strobel wrote:

I understand this is not a bug in the sense that it displays wrong
information, nor that I cannot get the information in a different way.
The problem is that the proctitle functionality, which is very
convenient and much faster than typing the SELECT above, is diminished
by easily misleading people when it displays this id in hex encoding
without zero padding.

Nothing prevents you to have a bash alias or a custom script doing
that. It is only a matter of minutes to have something working, and
for example psql -At will save you any parsing code you need to have
when querying ps. If you want as well to query the lag in bytes
between both nodes, simply compare the LSN position and you would get
a result in bytes.
--
Michael

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

Michael Paquier wrote:

On Tue, Sep 15, 2015 at 2:27 PM, J�rgen Strobel wrote:

I understand this is not a bug in the sense that it displays wrong
information, nor that I cannot get the information in a different way.
The problem is that the proctitle functionality, which is very
convenient and much faster than typing the SELECT above, is diminished
by easily misleading people when it displays this id in hex encoding
without zero padding.

Nothing prevents you to have a bash alias or a custom script doing
that.

I agree with J�rgen, we should zero-pad this. This stuff is
user-unfriendly enough without having to count chars or write shell
functions.

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

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

On Tue, 15 Sep 2015 18:40:02 -0300
Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

Michael Paquier wrote:

On Tue, Sep 15, 2015 at 2:27 PM, Jürgen Strobel wrote:

I understand this is not a bug in the sense that it displays wrong
information, nor that I cannot get the information in a different way.
The problem is that the proctitle functionality, which is very
convenient and much faster than typing the SELECT above, is diminished
by easily misleading people when it displays this id in hex encoding
without zero padding.

Nothing prevents you to have a bash alias or a custom script doing
that.

I agree with Jürgen, we should zero-pad this. This stuff is
user-unfriendly enough without having to count chars or write shell
functions.

+1

-dg

--
David Gould daveg@sonic.net
If simplicity worked, the world would be overrun with insects.

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