-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Build
-
Storage Engines
-
5
-
2024-03-19 - PacificOcean
We've recently been butting up against a couple of limitations around what WiredTiger expects, software-wise. There's the qsort_r situation, which is currently blocking a bugfix (a hand-rolled quicksort has proven too slow in practice, while the system qsort_r isn't possible to implement without specifying which platforms we support).
There's the ftruncate thing - our documentation says we need POSIX 1003.1, which includes ftruncate, but we bend over backwards to support systems without it, and it's currently holding up a chunk cache change.
I think there would other benefits to WiredTiger users - enumerating which platforms we support would let potential users make a more informed decision about whether relying on WiredTiger is reasonable (if a NetBSD user comes along, will it compile but then fail in mysterious corner cases at runtime? Would small patches to make it work on that platform be accepted?). We don't even need to phrase this as supported/not supported: outlining which systems we test on, and guarantee to keep working, would be a great start, especially if we state that we welcome bug reports and patches for other systems.
Finally, we have an explicit listing (in CMake) of hardware architectures we do and do not support. Admittedly this is more intended for WiredTiger standalone builds, but there's some precedent for not supporting certain platforms. (If nothing else, I think we could document this a little better - these platforms aren't listed on the reference guide homepage, "Building and installing on POSIX" page, or the "overview and features" page.)