> 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.
My apologies for the late response here. I spent some time looking at
this yesterday and came to the conclusion that we can add dshash tests
to test_dsm_registry, which already allocates a dshash via
GetNamedDSHash(). However, I also realized that the API has a gap: callers
cannot set a size limit on the dshash. I need this for the test, but
more importantly it's a limitation of the API itself. So I plan to
target v20 for the tests, as it's likely too late for v19. To start, I've
submitted a patch for allowing callers to set a size limit on a
GetNamedDSHash()-allocated dshash [1].
[1] https://commitfest.postgresql.org/patch/6655/
--
Sami
