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

pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

From
Joe Conway
Date:
I wonder why "Latest checkpoint's NextXID" is formated like this:

8<-------------------------printf(_("Latest checkpoint's NextXID:          %u/%u\n"),
ControlFile.checkPointCopy.nextXidEpoch,      ControlFile.checkPointCopy.nextXid); 
8<-------------------------

Shouldn't it use "%X/%X", same as e.g. "Prior checkpoint location" and
all the other XIDs?

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


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

From
Heikki Linnakangas
Date:
On 29/12/15 07:14, Joe Conway wrote:
> I wonder why "Latest checkpoint's NextXID" is formated like this:
>
> 8<-------------------------
>     printf(_("Latest checkpoint's NextXID:          %u/%u\n"),
>            ControlFile.checkPointCopy.nextXidEpoch,
>            ControlFile.checkPointCopy.nextXid);
> 8<-------------------------
>
> Shouldn't it use "%X/%X", same as e.g. "Prior checkpoint location" and
> all the other XIDs?

No. The "locations" in the output are WAL locations. Those are 
customarily printed with %X/%X. But NextXID is a transaction ID, those 
are printed in decimal, with %u.

- Heikki




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

From
José Luis Tallón
Date:
On 12/29/2015 01:18 PM, Heikki Linnakangas wrote:
> On 29/12/15 07:14, Joe Conway wrote:
>> I wonder why "Latest checkpoint's NextXID" is formated like this:
>>
>> 8<-------------------------
>>     printf(_("Latest checkpoint's NextXID:          %u/%u\n"),
>>            ControlFile.checkPointCopy.nextXidEpoch,
>>            ControlFile.checkPointCopy.nextXid);
>> 8<-------------------------
>>
>> Shouldn't it use "%X/%X", same as e.g. "Prior checkpoint location" and
>> all the other XIDs?
>
> No. The "locations" in the output are WAL locations. Those are 
> customarily printed with %X/%X. But NextXID is a transaction ID, those 
> are printed in decimal, with %u.

But Joe has a point here.... Others could also be confused if he doubted 
about this.

"Latest checkpoint's NextXID:          %u:%u\n", maybe ??    (slash becomes colon)

Worst part: fuzzies the translations unnecesarily

    / J.L.




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

From
Tom Lane
Date:
José Luis Tallón <jltallon@adv-solutions.net> writes:
> On 12/29/2015 01:18 PM, Heikki Linnakangas wrote:
>> On 29/12/15 07:14, Joe Conway wrote:
>>> Shouldn't it use "%X/%X", same as e.g. "Prior checkpoint location" and
>>> all the other XIDs?

>> No. The "locations" in the output are WAL locations. Those are 
>> customarily printed with %X/%X. But NextXID is a transaction ID, those 
>> are printed in decimal, with %u.

> But Joe has a point here.... Others could also be confused if he doubted 
> about this.

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.
        regards, tom lane



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

From
Joe Conway
Date:
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?

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


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

From
Simon Riggs
Date:
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

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

From
José Luis Tallón
Date:
On 12/30/2015 06:46 AM, Simon Riggs wrote:
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."

So? If I am guessing correctly, you propose to use %llu (more precisely, UINT64_FORMAT) ?
    (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


Thanks,

    / J.L.

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

From
Tom Lane
Date:
José Luis Tallón <jltallon@adv-solutions.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