On Thu, Mar 26, 2026 at 04:26:33PM -0400, Andres Freund wrote: > I think tests like this do have value and I'd definitely run them first while > hacking on code related to dshash, rather than relying on the regression tests > or such. E.g. having test_aio was invaluable to being able to get AIO into a > stable state. When hacking on something with complicated edge cases I'd just > add a test for it, making development faster as well as ensuring the > complicated case continues to work into the future.
These test modules have a lot of value because they are cheap to run and are very usually able to reproduce edge cases that no other place of the code tree would be able to reach in a predictible way. Cheap, fast and reliable is good. On top of that they can serve as code template. Bonus points. > However, creating its own test module for small parts of the codebase doesn't > quite make sense to me. A pretty decent chunk of the test is just boilerplate > to add a new module, and every new test module requires its own cluster, which > adds a fair bit of runtime overhead, particularly on windows. I think > test_dsa, test_dsm_registry, test_dshash should just be one combined test > module, they're testing quite closely related code. Yeah, perhaps grouping all the DSA things into a single module would be OK, with a parallel schedule that would speed up things. It depends on the complexity and the size of the module to me. Saying that, I think that the shape of the proposed test_dshash is wrong: it proposes one SQL function that does a bunch of dshash-related operations in a single function call, in a random manner. We have a shared memory state that can survive across SQL calls, making it a set of thinner SQL function that wrap directly dshash calls able to manipulate the table would feel much more natural to me. And it would be easier to design edge cases in the SQL scripts themselves. -- Michael
signature.asc
Description: PGP signature
