Skip to content

Possible MVStore compaction issue #3097

Closed

Description

@wburzyns

Using current master, the attached procedure will end with 'MVStoreExeception: Double mark' after 2nd run, after that the store is unopenable (with the same error). This won't happen if 'store.compactFile(200);' is commented out.

MStore possible bug.txt

Activity

  1. wburzyns commented on Apr 26, 2021

    @wburzyns
    Author

    Actually it will happen without explicit compaction, but later (when auto-compaction kicks in).

    This issue might be related to issues #2752 and #3031.

  2. self-assigned this
    on Apr 27, 2021
  3. andreitokar commented on Apr 27, 2021

    @andreitokar
    Contributor

    @wburzyns, Thanks for posting a test case. I am able to reproduce the problem.
    This looks like a bug in MVStore.rollbackTo(). This method is relatively lightly tested, since it is not used by H2. It is not thread-safe by design, and IMHO should be deprecated/removed. I wonder what is your use case for it? Can't TransactionStore be used here instead, if you need some sort of a roll back functionality?
    Anyway, I've created a PR, which hopefully will fix your issue.

  4. wburzyns commented on Apr 27, 2021

    @wburzyns
    Author

    At the moment I've no specific use for this method. I was just playing around the MVStore.

    BTW Could you advise how many versions are retained in case of a file store? For in-memory stores there is a method MVStore.setVersionsToKeep (5 by default) but there is no similar method for file stores.

  5. andreitokar commented on Apr 28, 2021

    @andreitokar
    Contributor

    MVStore version will be retained if it falls within explicit number of versions to keep (default 5 for in-memory and 0 otherwise) or if it is still in use by any operation in progress. Operation demarcation is done by MVStore.registerVersionUsage()/deregisterVersionUsage(). There is also indirect time-based barrier, which prevents otherwise unused chunks to be garbage collected (their space re-used), which is governed by MVStore.setRetentionTime() (default 45 sec).
    Therefore, if application uses mvstore with filestore with zero retention time, and is it's not calling de/registerVersionUsage(), only current version (no historical versions at all) is retained, and even trivial map iteration can blow up in face of concurrent updates and version advancement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions