>
> 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.
You're completely right. This is a first of making xid's 64-bit proposed
[1] i.e, making SLRU
On Fri, 1 Apr 2022 at 14:13, Pavel Borisov 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
Dagfinn Ilmari Mannsåker writes:
> Even if a cluster was consuming a million XIDs per second, it would take
> over half a million years to wrap around the 64bit range. Is that really
> something we should worry about?
>
> ilmari@[local]:5432 ~=# select 2::numeric^64/10^9/3600/24/365;
Oops, that
Hi!
In my view, FullTransactionId type was implemented without considering 64
bit wraparound. Which seems to be unlikely to happen. Then on that basis
xid8 type was created. Details of that particular implementation
infiltrated into documentation and became sort of normal. In my opinion,
Pavel Borisov writes:
> 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 database cluster."
>
>
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 database cluster."
As a consequence of [1] xid8 can have
