On Wed, Mar 13, 2024 at 8:05 PM John Naylor <johncnaylo...@gmail.com> wrote: > > On Wed, Mar 13, 2024 at 8:39 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > As I mentioned above, if we implement the test cases in C, we can use > > the debug-build array in the test code. And we won't use it in AND/OR > > operations tests in the future. > > That's a really interesting idea, so I went ahead and tried that for > v71. This seems like a good basis for testing larger, randomized > inputs, once we decide how best to hide that from the expected output. > The tests use SQL functions do_set_block_offsets() and > check_set_block_offsets(). The latter does two checks against a tid > array, and replaces test_dump_tids().
Great! I think that's a very good starter. The lookup_test() (and test_lookup_tids()) do also test that the IsMember() function returns false as expected if the TID doesn't exist in it, and probably we can do these tests in a C function too. BTW do we still want to test the tidstore by using a combination of SQL functions? We might no longer need to input TIDs via a SQL function. > Funnily enough, the debug array > itself gave false failures when using a similar array in the test > harness, because it didn't know all the places where the array should > have been sorted -- it only worked by chance before because of what > order things were done. Good catch, thanks. > I squashed everything from v70 and also took the liberty of switching > on shared memory for tid store tests. The only reason we didn't do > this with the radix tree tests is that the static attach/detach > functions would raise warnings since they are not used. Agreed to test the tidstore on shared memory. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com