Re: Is monotonous xid8 is a right way to do? - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: Is monotonous xid8 is a right way to do?
Date
Msg-id CAEze2WgL4xhTVh67ct-YB6Lmcpf+DUhA0Zujmg8_Oko3L5vVCw@mail.gmail.com
Whole thread Raw
In response to Is monotonous xid8 is a right way to do?  (Pavel Borisov <pashkin.elfe@gmail.com>)
Responses Re: Is monotonous xid8 is a right way to do?
List pgsql-hackers
On Fri, 1 Apr 2022 at 14:13, Pavel Borisov <pashkin.elfe@gmail.com> wrote:
>
> Hi hackers!
>
> Now we have two data types xid and xid8. The first one (xid) makes a numeric ring, and xid8 are monotonous.
>
> As per [1] "Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a
databasecluster."
 
>
> As a consequence of [1] xid8 can have min/max functions (committed in [2]), which xid can not have.
>
> When working on 64xid patch [3] we assume that even 64xid's technically can be wraparound-ed, although it's very much
unlikely.I wonder what is expected to be with xid8 values at this (unlikely) 64xid wraparound?
 
>
> What do you think about this? Wouldn't it be better to change xid8 to form a numeric ring like xid? I think it is
necessaryfor any 64-wraparound-enabled implementation of 64xids.
 
>
> Please feel free to share your thoughts.

Assuming that each Xid is WAL-logged (or at least one in 8) we won't
see xid8 wraparound, as our WAL is byte-addressable with only 64 bits
used as the identifier. As such, we can only fit a maximum of 2^61
xid8s in our WAL; which is less than what would be needed to wrap
around.

Addressed another way: If we'd have a system that consumed one xid
every CPU clock; then the best available x86 hardware right now would
currently consume ~ 5.5B xids every second. This would still leave
around 100 years of this system running non-stop before we'd be
hitting xid8 wraparound (= 2^64 / 5.5e9 (xid8 /sec) / 3600 (min /hour)
/ 730 (hour / month)/ 12 (month /year)).

I don't think we'll have to consider that an issue for now. Maybe,
eventually, if we start doing distributed transactions where
transaction IDs are reasonably consumed at a rate higher than 5B /sec
(and not logged at that rate) we can start considering this to be a
problem.

A different and more important issue (IMO) is that the xlog record
header currently only supports 32-bit xids -- long-running
transactions can reasonably see a xid4 wraparound in their lifetime.

Enjoy,

Matthias van de Meent



pgsql-hackers by date:

Previous
From: Dagfinn Ilmari Mannsåker
Date:
Subject: Re: Is monotonous xid8 is a right way to do?
Next
From: Pavel Borisov
Date:
Subject: Re: Is monotonous xid8 is a right way to do?