Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format
От | José Luis Tallón |
---|---|
Тема | Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format |
Дата | |
Msg-id | 5683D1E0.7080603@adv-solutions.net обсуждение исходный текст |
Ответ на | Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: