On Tue, Jul 30, 2019 at 01:08:37PM -0400, Randall S. Becker wrote: > t0016: oidmap > > Subtest 6 had an ordering issue. We do not know whether the problem is the code or the test result not keeping up with the code changes. > --- expect 2019-07-30 16:56:36 +0000 > +++ actual 2019-07-30 16:56:36 +0000 > @@ -1,6 +1,6 @@ > NULL > NULL > NULL > +7c7cd714e262561f73f3079dfca4e8724682ac21 3 > 139b20d8e6c5b496de61f033f642d0e3dbff528d 2 > d79ce1670bdcb76e6d1da2ae095e890ccb326ae9 1 > -7c7cd714e262561f73f3079dfca4e8724682ac21 3 This one is very curious. It's iterating a hash, which _seems_ like it would produce non-deterministic output. But neither this test nor the hashmap test it is based on sorts the output, and they pass consistently for me. I assume that's because while hash ordering is not guaranteed, it happens to be the same as long the pattern of inserts is the same (with our implementation, which does not do any hash randomization). But I am scratching my head as to what could be different on your platform that would cause a different ordering (especially when the hashmap test this is based on doesn't get one!). I guess in some sense it may not be worth tracking down, and we should just sort the output of a hash iteration unconditionally when comparing it to expected output. -Peff
