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