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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format
Дата
Msg-id 11245.1451489369@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format  (José Luis Tallón <jltallon@adv-solutions.net>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Better detail logging for password auth failures
Следующее
От: Evgeniy Shishkin
Дата:
Сообщение: Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)