Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, José Luis Tallón <jltallon(at)adv-solutions(dot)net>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format
Date: 2015-12-30 05:46:57
Message-ID: CANP8+jKicB5Ux15f+toXRfJpEF7RQfDx3_ANH7tXs4qqrY8d4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30 December 2015 at 00:17, Joe Conway <mail(at)joeconway(dot)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/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2015-12-30 07:16:28 More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)
Previous Message Thomas Munro 2015-12-30 04:15:23 Re: Proposal: "Causal reads" mode for load balancing reads without stale data