RE: Should we add xid_current() or a int8->xid cast? - Mailing list pgsql-hackers

Hi Thomas,

Please let me ask something about wraparound problem.

+static FullTransactionId
+convert_xid(TransactionId xid, FullTransactionId next_fxid)
 {
-    uint64        epoch;
+    TransactionId next_xid = XidFromFullTransactionId(next_fxid);
+    uint32 epoch = EpochFromFullTransactionId(next_fxid);
 
...
 
-    /* xid can be on either side when near wrap-around */
-    epoch = (uint64) state->epoch;
-    if (xid > state->last_xid &&
-        TransactionIdPrecedes(xid, state->last_xid))
+    if (xid > next_xid)
         epoch--;
-    else if (xid < state->last_xid &&
-             TransactionIdFollows(xid, state->last_xid))
-        epoch++;
 
-    return (epoch << 32) | xid;
+    return FullTransactionIdFromEpochAndXid(epoch, xid);


ISTM codes for wraparound are deleted. Is that correct?
I couldn't have read all related threads about using FullTransactionId but
does using FullTransactionId avoid wraparound problem? 

If we consider below conditions, we can say it's difficult to see wraparound
with current disk like SSD (2GB/s) or memory DDR4 (34GB/s), but if we can use 
more high-spec hardware like HBM3 (2048GB/s), we can see wraparound. Or do
I say silly things?

* 10 year system ( < 2^4 )
* 1 year = 31536000 ( = 60 * 60 * 24 * 365) secs  ( < 2^25 )
* 2^35 ( = 2^64 / 2^4 / 2^25) transactions we can use in each seconds
* we can write at (2^5 * 2^30 * n) bytes/sec = (32 * n) GB/sec if we use 'n'
  bytes for each transactions.

Is there any agreement we can throw the wraparound problem away if we adopt
FullTransactionId?


Thanks
--
Yoshikazu Imai