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

The following bug has been logged on the website:

Bug reference:      13620
Logged by:          Jürgen Strobel
Email address:      juergen+postgresql@strobel.info
PostgreSQL version: 9.4.4
Operating system:   Linux, REL6
Description:


Hello,

I frequently use "watch ps xf" to monitor server restarts etc., it's really
a great, simple and effective tool. But there is a minor formatting issue,
which has caused considerable confusion not only for me already.

For example:

postgres$ ps xf
... /usr/pgsql-9.4/bin/postmaster -D /mnt/db/.../data
... \_ postgres: startup process   recovering 00000005000004B500000007
... \_ postgres: wal receiver process   streaming 4B5/78A2C80
... \_ postgres: wal sender process replication [local] streaming
4B5/78A2C80

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

Best regards,
Jürgen

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

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

On Tue, Sep 15, 2015 at 2:27 PM, J=C3=BCrgen 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.
--=20
Michael

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

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=C3=BCrgen 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.
> >=20
> > Nothing prevents you to have a bash alias or a custom script doing
> > that.
>=20
> I agree with J=C3=BCrgen, we should zero-pad this.  This stuff is
> user-unfriendly enough without having to count chars or write shell
> functions.

+1

-dg=20

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