A safer way is to fetch and use a ts from pd like pdCli.GetTS(ctx). math.MaxUint64 cannot provide snapshot semantics.

I think we don't need snapshot semantics here. This function determines if we can use the fast path for data reorganization:

• if it returns false, but actually it is true, we won't enter the fast path
• if it returns true, but actually it is false, we enter the fast path, and the following insertions will be handled by dual-write mechanism (txn mode) or temp-index-merge mechanism (ingest mode). This is covered by test https://github.com/pingcap/tidb/pull/57778/files#diff-2998ac87ef4adb20bfc6bf8ce58ace7015800e57f330bacad08cba4b90350300R908

Another layer of semantics for safety is that, in the transaction layer and TiKV, the use of math.MaxUint64 is only expected for primary key point-get autocommit reads. Other scenarios should not use math.MaxUint64 for reads. It's better to stick to PD-allocated timestamps instead.

I think we don't need snapshot semantics here.

Did you mean that you don't need a consistent snapshot, so you try to use a weaker or looser way for the reading?

I think reading with MaxUint64 seems to be much more special than you, as well as many other developers, might think. At least it is so after implementing async commit. Maybe it's better if you only consider whether the overhead of getting a new ts from PD is so unacceptable to you.

reading with MaxUint64 seems to be much more special

can you give more detail? or some doc link?

the use of math.MaxUint64 is only expected for primary key point-get autocommit reads. Other scenarios should not use math.MaxUint64 for reads

In my understanding, snapshot reading is not a pure "reading" at TiKV. It updates the Max TS so caused side effect to async commit. #57769 https://cn.pingcap.com/blog/async-commit-principle/

In my understand, snapshot reading is not a pure "reading" at TiKV. It has side effect to async commit. #57769

that's too bad, a read operation corrupt the entire cluster

can you give more detail? or some doc link?

There's not any document dedicated to talking about this as far as I know. There's many special handling for reading with MaxUint64. For example, TiKV skipping updating the max_ts using it; special lock-ignoring logic when checking read-write conflict; etc. It also used to cause difficulty for us in developent or optimization work.

snapshot reading is not a pure "reading" at TiKV.

The max_ts in async commit / 1PC is an approach to let writing transactions to avoid affecting other reading operations. It tells the latest timestamp allocated by PD that has been used on this TiKV node. It's quite doubtful to me whether this can be the reason to say that the reading is not "pure".

that's too bad

The design is based on the fact that the reads and writes are strongly ordered by PD's globally unique and monotonic TSO allocation, and writing cannot change the snapshot has been read, otherwise the snapshot becomes not repeat-readable, then it's no longer a snapshot. You may think that this makes async commit transactions committed to an incorrect future version and cause its result not readable, and things would be all better if async commit not exists. But that's the choice that async commit transactions made to avoid breaking your snapshot. If the transaction is committed in 2PC mode which is not related to the max_ts mechanism, there's still another form of corruption, that is, your snapshot is changed and becomes not repeat-readable. If you believe there's something bad, I think the bad part is that the strong ordering that's supposed to be provided by TSO is broken.

for bad, i mean a read only operation has side effects, and it corrupt the entire cluster

read only operation shouldn't have such effects as a common design practice AFAIK