Why does crdb have to wait because of clock synchronization uncertainty?

the crdb use hlc(hybrid logical clocks) to make orders of transactions, and hlc can identify and return consistent global snapshots without needing to wait out clock synchronization uncertainties and without needing prior coordination,in a posteriori fashion(from the paper published by Sandeep Kulkarni, Murat Demirbas, Deepak Madeppa, Bharadwaj Avva, and Marcelo Leone). so why does crdb have to wait because of clock synchronization uncertainty(about the setting of 500ms of clock offset)?
I feel puzzled very much! thx!

I’d recommend reading https://github.com/cockroachdb/cockroach/blob/master/docs/design.md#lock-free-distributed-transactions

Thanks a lot . That’s complicated , I have read several times about the article before I issue this new topic.and, I read again yesterday. so, i think CockroachDB use HLC just to lower overhead.
the second question :why when a transaction restarts, it reuse the same txn id? is the txn a timestamp? Is there any special reason about the same txn id ?
the third question is how every node in CockroachDB cluster know the range position which preserve the transaction status?
thx !

Indeed, the HLC does not generally play an important part in our correctness guarantees.

the second question :why when a transaction restarts, it reuse the same txn id? is the txn a timestamp? Is there any special reason about the same txn id ?

Depending on the type of restart, the transaction may or may not keep the same ID. When we can, we keep the same txn ID because, if the transaction wrote data and laid down intents before restarting, those intents will help prevent conflicts with other transactions. The assumption is that, after restart, the transaction is likely to write the same data.

the third question is how every node in CockroachDB cluster know the range position which preserve the transaction status?

I don’t know what you’re referring to. The “range position” is not a concept we use.

I mean the reseaved area preserving the transaction status.

The location of the transaction record is stored in the write intents.

"Writer encounters more recently read key: The read timestamp cache is consulted on each write at a node. If the write’s candidate timestamp is earlier than the low water mark on the cache itself (i.e. its last evicted timestamp) or if the key being written has a read timestamp later than the write’s candidate timestamp, this later timestamp value is returned with the write. A new timestamp forces a transaction restart only if it is serializable."
can u introduce about the ‘read timestamp cache’? i dont know the mechanism about it.