pg_resetxlog display bogosity

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

I wonder if pg_resetxlog should display the actual pg_control values in
one section, and the values that would be set after a reset in a
different section, so that it is extra clear.

Seems reasonable, although I'd suggest labeling the first section as
"Current pg_control values" or some such, if you want clarity.

regards, tom lane

Is this a TODO item?

---------------------------------------------------------------------------

Alvaro Herrera wrote:

I just noticed that if I specify pg_resetxlog a timeline ID with the -l
switch, it will display this value as "TimeLineID of latest checkpoint".
Which is not really the truth.

I wonder if pg_resetxlog should display the actual pg_control values in
one section, and the values that would be set after a reset in a
different section, so that it is extra clear. So it would look like

pg_control values:

pg_control version number: 903
Catalog version number: 201004261
Database system identifier: 5509100787461288958
Latest checkpoint's TimeLineID: 1
Latest checkpoint's NextXID: 0/667
Latest checkpoint's NextOID: 16390
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Latest checkpoint's oldestXID: 654
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 0
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1996
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by value

Values to be used after reset:

First log file ID: 14
First log file segment: 28
TimeLineID: 57

(I'd also like to point out that the "Latest checkpoint's" phrasing is awkward
and cumbersome for translated output, but I'm refraining from suggest a
reword because it'd complicate matters for programs that try to read the
output)

--
��lvaro Herrera <alvherre@alvh.no-ip.org>

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

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Excerpts from Bruce Momjian's message of vie feb 18 23:41:18 -0300 2011:

Is this a TODO item?

Only to me, it seems.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

2011/2/22 Alvaro Herrera <alvherre@commandprompt.com>:

Excerpts from Bruce Momjian's message of vie feb 18 23:41:18 -0300 2011:

Is this a TODO item?

Only to me, it seems.

looks like you suggestion get positive impact so far :-)

+1 to fix the bogosity output rather than waiting for 9.2 via a todo ....

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support