[SERVER-49095] Evaluate running unittests with WT Created: 25/Jun/20  Updated: 06/Dec/22  Resolved: 01/Mar/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Henrik Edin Assignee: Backlog - Storage Execution Team
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Storage Execution
Participants:

 Description   

When ephermeralfortest is complete and all unittests support document level storage engines, it might be possible to run unittests with WiredTiger. Supporting multiple storage engines reduces the risk of building in assumptions about the storage engine in the tests.



 Comments   
Comment by Andrew Morrow (Inactive) [ 25/Jun/20 ]

Unfortunately, compiling the unit tests is one of the most expensive tasks we have in terms of build time. The new dynamic linker mode has improved things dramatically for the builders where it applies (notably, non-windows non-shipping), but doubling the amount of compile work is probably not a viable option. I also worry about making the unit tests modal. To be clear, I do like the idea of the additional coverage here: knowing that the unit tests that shouldn't depend on the storage engine are in fact independent of storage engine seems like a win. But it seems like there are at least three classes of tests: tests that don't use a storage engine and are unaffected or agnostic to this, tests that do use a storage engine and should be storage engine independent, and tests which test a specific storage engine which should not be run with "alternates".

So I think I agree with your analysis that this is something more like a mini-project.

Comment by Henrik Edin [ 25/Jun/20 ]

I think if the evaluation on how far we are from being able to use WT in unittests (this ticket) is successful, we would need to think about how to make it actually work. I envisioned it as a separate builder where we select the storage engine with a compile time flag to make sure we link in the correct libraries. I think the least amount of work is the key here, being able to select storage engine at runtime does not seem that important.

But perhaps this is more work than a single ticket and is more like a mini project. I think a PoC/evaluation is a good first step.

Comment by Andrew Morrow (Inactive) [ 25/Jun/20 ]

henrik.edin - Can you explain in more detail how this would work? Would we need to recompile the unit tests? Or would there be a startup flag that controlled which storage engine we used, and we ran them twice? How would we identify which tests were modal? I think there are a lot of subtleties to getting this done.

Comment by Henrik Edin [ 25/Jun/20 ]

I don't think TSAN can work with WT? But TSAN on the builders using the radix tree storage engine should not be affected by adding an additional WT based builder without TSAN.

Comment by Andrew Morrow (Inactive) [ 25/Jun/20 ]

What would the implications be for TSAN if we did this?

Generated at Thu Feb 08 05:18:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.