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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)
Следующее
От: Aleksander Alekseev
Дата:
Сообщение: Re: Patch: fix lock contention for HASHHDR.mutex