Ray Yan

@ekexium @iosmanthus PTAL

首先感谢你的付出。 有个问题想问一下，emoji表情看debug日志，msg的type是47，content是空，消息中不是应该有对应表情的cdn_url地址吗？或者直接转成文字也是可以接受的。

@ekexium @iosmanthus PTAL

@ekexium @iosmanthus PTAL

@ekexium I want take `u64::MAX` as timestamp to perform `newest snapshot read`, and I need the transaction context of the snapshot. Used like this https://github.com/tidbcloud/tikv-service/blob/1fc28af630db850d5eeccf087705bde52e18577e/src/tikv/string.rs#L55

@ekexium Yes, it is just used for `one key read ` in use case above.

@ekexium Any suggestions to use `u64::MAX` timestamp for `just single key read` case in a transaction, or we can add a new method like `begin_latest_readonly()` to client?

I think we should not restrict to get multiple keys with the latest committed in a transaction, just like create a new snapshot with timestamp `u64::MAX`, but want to use...

> Read operations can affect writes and the correctness of transactions. We can only use timestamp::max() where TiKV has handled it specially I checked the logic in client-go, and it...

> Then `Snapshot` already gives what you need? > > > No, I prefer to using an inner transaction directly which can keep my code simple. :-)