crl-release-23.2: db: ensure Metrics.WAL.BytesWritten is nondecreasing #3569
Conversation
|
This change is |
There was a problem hiding this comment.
Reviewed 5 of 5 files at r1.
Reviewable status: 2 of 6 files reviewed, 1 unresolved discussion (waiting on @jbowens and @RaduBerinde)
testdata/metrics line 487 at r2 (raw file):
unknown command: <<<<<<< >>>>>>> 9027c15f (db: update flushableEntry.logSize during flushable ingest)
I think you have merge conflicts that need resolution
There was a problem hiding this comment.
Reviewable status: 2 of 6 files reviewed, 1 unresolved discussion (waiting on @dhartunian and @RaduBerinde)
testdata/metrics line 487 at r2 (raw file):
Previously, dhartunian (David Hartunian) wrote…
I think you have merge conflicts that need resolution
embarassing, thanks
|
bumping |
There was a problem hiding this comment.
Reviewable status: 2 of 6 files reviewed, 1 unresolved discussion (waiting on @dhartunian)
testdata/metrics line 487 at r2 (raw file):
Previously, jbowens (Jackson Owens) wrote…
embarassing, thanks
[nit] These are fixed in the subsequent commit but not this one
Performing a flushable ingestion causes two WAL rotations: one to switch away from the WAL corresponding to the mutable memtable to a temporary, intermediary WAL for the ingestion, and one to switch to the next mutable memtable's WAL. Both these WAL rotations ignored the previous log size, omitting the propagation to the corresponding flushable. This commit fixes this bug, propagating the logSize appropriately.
The Metrics.WAL.BytesWritten metric is intended to be a monotonically increasing counter of all bytes written to the write-ahead log. Previously, it was possible for this metric to violate monotonicity immediately after a WAL rotation. The d.logSize value—which corresponds to the size of the current WAL—was not reset to zero. It was only reset after the first write to the new WAL. Close cockroachdb#3505.
|
TFTR! |
23.2 backport of #3555