Add integration test for commitlog compression

[coolreader18]

Description of Changes

Followup to #2504. Not sure why I didn't have this as part of that, I think I thought it would take a while to write this.

Expected complexity level and risk

n/a

Testing

• yes

[gefjon]

Thanks, looks good to me! I'd also like someday to have a test that's fully integrated with the database as a whole, but I don't consider that high-prio.

[joshua-spacetime]

I do think we should add a higher-level integration test here. At the very least we should have a test that checks the segments since the last snapshot and makes sure they are not compressed. In the absence of a test like this, I would argue that we need a benchmark for replaying from the latest snapshot, since we care about the performance here.

[coolreader18]

Do you have any suggestions for how to go about that? RelationalDb doesn't really expose that kind of low level stuff.

[kim]

Do you have any suggestions

Maybe just use the datastore directly, like the cutlery does?

[coolreader18]

I do think we should add a higher-level integration test here. At the very least we should have a test that checks the segments since the last snapshot and makes sure they are not compressed. In the absence of a test like this, I would argue that we need a benchmark for replaying from the latest snapshot, since we care about the performance here.

I've been trying, and I really can't figure out a good way to write this test without just exposing a ton of internals from RelationalDb or the datastore, like literally adding a getter for a RwLockWriteGuard<'_, repo::Fs>. I do think that the benchmark makes the most sense, since that's really what this is a proxy for.