Skip site navigation (1) Skip section navigation (2)

pg_resetxlog display bogosity

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: pg_resetxlog display bogosity
Date: 2010-08-31 18:08:58
Message-ID: 1283277511-sup-2152@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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(at)alvh(dot)no-ip(dot)org>

Responses

pgsql-hackers by date

Next:From: Kris JurkaDate: 2010-08-31 18:13:47
Subject: Re: Trouble with COPY IN
Previous:From: Magnus HaganderDate: 2010-08-31 17:46:22
Subject: Re: git: uh-oh

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group