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

From: José Luis Tallón <jltallon(at)adv-solutions(dot)net>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 12:45:20
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 12/30/2015 06:46 AM, Simon Riggs wrote:
> On 30 December 2015 at 00:17, Joe Conway <mail(at)joeconway(dot)com
> <mailto: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.
> "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."

So? If I am guessing correctly, you propose to use %llu (more precisely,
(please correct me if I got it wrong)

IMHO, we have been telling users that XIDs are 32bits forever, so
showing a 64bits int where an XID is expected can easily induce confusion.
Moreover, the "epoch : whatever" format is widely used (Debian &
derivatives, just to name some) and understood...
... but I might be wrong.

Any format different from %X/%X seems better than what we have
know, in any case


/ J.L.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2015-12-30 13:01:37 Re: Patch: fix lock contention for HASHHDR.mutex
Previous Message Tomas Vondra 2015-12-30 12:24:31 Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)