Page MenuHomePhabricator

recover: only apply last journal record per file (issue6423)
ClosedPublic

Authored by joerg.sonnenberger on May 17 2021, 10:51 PM.

Details

Summary

This got broken in 2019 when the size check was introduced. It is most
noticable when dealing with transactions that involve an inline to
non-inline revlog storage transaction. It wasn't seen as much at the
time because the in-memory journal actually de-duplicated the entry
implicity, but since 63edc384d3b7 the on-disk journal is used for
rollback as well as recover.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Does the order of the truncates actually not matter, for concurrent readers? I don't really see how it could matter (linkrevs should make it possible to ignore everything not committed), but before looking at the rollback code, I imagined it truncated in reverse order of writes (and looking it up, it's what's described in the initial revlog paper).

I can't find documentation that dict() guarantees to favor the rightmost key, but I'm assuming it's true anyway.
Modulo the question about order of truncates, this looks good.

Also, can you put (issue6423) in the first line of the commit message, so the bugzilla magic closes the issue?

joerg.sonnenberger retitled this revision from recover: only apply last journal record per file to recover: only apply last journal record per file (issue6423).May 19 2021, 9:54 AM
This revision was not accepted when it landed; it landed in state Needs Review.
This revision was automatically updated to reflect the committed changes.