Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format
Date
Msg-id CANP8+jKicB5Ux15f+toXRfJpEF7RQfDx3_ANH7tXs4qqrY8d4A@mail.gmail.com
Whole thread Raw
In response to Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format  (Joe Conway <mail@joeconway.com>)
Responses Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format
List pgsql-hackers
On 30 December 2015 at 00:17, Joe Conway <mail@joeconway.com> wrote:
On 12/29/2015 07:15 AM, Tom Lane wrote:
> Yeah.  Use of the same x/y notation with two different bases seems like
> a recipe for confusion.  It's probably too late to do anything about
> this for 9.5, but I'd be +1 for adopting Jose's suggestion or some
> other formatting tweak in HEAD.

I made the "%u/%u" -> "%u:%u" change in the controldata patch I just
posted, but I suppose I should commit that separately. Any complaints
about that?

There is already long precedent about how to represent an XID with an epoch... and it is neither of those two formats.

http://www.postgresql.org/docs/devel/static/functions-info.html
"Table 9-63. Transaction IDs and Snapshots"
"The internal transaction ID type (xid) is 32 bits wide and wraps around every 4 billion transactions. However, these functions export a 64-bit format that is extended with an "epoch" counter so it will not wrap around during the life of an installation."

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

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Proposal: "Causal reads" mode for load balancing reads without stale data
Next
From: David Rowley
Date:
Subject: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)