storage: populate timestamp field in lock table values #111223
Conversation
This commit starts writing the Timestamp field in lock table MVCCMetadata values for shared and exclusive locks. This mirrors the behavior of intent locks. This is not strictly needed, as the timestamp is always equal to txn.WriteTimestamp, but it is cheap to do and helps unify some stats logic, which uses this field to compute "lock age". Maybe we'll get rid of this for all lock strengths one day... Release note: None
|
This change is |
There was a problem hiding this comment.
Reviewed 6 of 6 files at r1, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @nvanbenschoten and @sumeerbhola)
-- commits line 10 at r1:
The GC queue also uses it to compute "lock age", so can we really get rid of it one day? Or were you imagining we'd get rid of this intent age concept from the GC queue as well?
There was a problem hiding this comment.
TFTR!
bors r+
Reviewable status:
Previously, arulajmani (Arul Ajmani) wrote…
The GC queue also uses it to compute "lock age", so can we really get rid of it one day? Or were you imagining we'd get rid of this intent age concept from the GC queue as well?
I was imagining that we would compute the lock age from the Txn.WriteTimestamp field, instead of the Timestamp field.
|
Build succeeded: |
Informs #109645.
This commit starts writing the
Timestampfield in lock tableMVCCMetadatavalues for shared and exclusive locks. This mirrors the behavior of intent locks. This is not strictly needed, as the timestamp is always equal toTxn.WriteTimestamp, but it is cheap to do and helps unify some stats logic, which uses this field to compute "lock age".Maybe we'll get rid of this for all lock strengths one day...
Release note: None