|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|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)|