From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | José Luis Tallón <jltallon(at)adv-solutions(dot)net> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, 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 15:29:29 |
Message-ID: | 11245.1451489369@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= <jltallon(at)adv-solutions(dot)net> writes:
> On 12/30/2015 06:46 AM, Simon Riggs wrote:
>> There is already long precedent about how to represent an XID with an
>> epoch... and it is neither of those two formats.
> 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.
Yeah. Also, if you look at xmin or xmax in any stored row, it's only
going to be 32 bits. If we make pg_controldata merge the epoch into a
decimal representation, it's going to be a serious PITA to manually
compare stored XIDs to the printout.
We've talked about making on-disk XIDs be effectively 64 bits (with
some trick or other to avoid taking a big space hit). If that ever
happens, and we start printing xmin/xmax as true 64-bit values, then
it'd be appropriate for pg_controldata to do the same. But right now
I think a split format is still the way to go.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Evgeniy Shishkin | 2015-12-30 15:39:06 | Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters) |
Previous Message | Tom Lane | 2015-12-30 15:18:35 | Re: Better detail logging for password auth failures |