Hi, On Wed, Sep 24, 2025 at 10:58:54PM +0200, Samuel Thibault wrote: > Michael Banck via Bug reports for the GNU Hurd, le mer. 24 sept. 2025 > 10:41:59 +0200, a ecrit: > > Those 0ns on qemu are the problem for the (probably artificial) stats > > isolation test,
Actually, it turned out not to be a problem. Macbook M4s show that behaviour (lots of 0ns and then nothing until 40ns) as well. The actual problem is that the thing Postgres checks (running a function which does nothing in the body twice) might be so fast that the timer resolution of the Hurd on qemu/kvm (3-4 us) does not always catch it. > > but the Postgres hackers are also very unhappy about > > proposing random sleep delays in their testsuite. > > Not introducing some delay would mean that with e.g. a 100GHz CPU it'd > surely just fail. Of course such speed won't actually exist, but this > is not just a theoretical case, it's something that could be built, > just way too expensive to come on the market, but that shows that yes, > some delay does make sense. If they really want to see the clock > advance for *sure*, they'd typically have to wait for two clock_getres() > durations. Otherwise, no standard will guarantee that time will have > advanced. I was a bit hasty here - Tom Lane, one of the core Postgres deveopers, seem to concur that the test is buggy and that the timer not advancing (contrary to going backwards) should be expected (at least for some reasonable timer resolution, which hasn't been established yet. 3-4 us is around 100-1000x slower than Linux from qemu to actual hardware). He writes: |I'd call this a bug in that test TBH. It'd be saner to |make the function do something like pg_sleep for 1ms. I've added a 1ms sleep to the test and so far it ran several thousand iterations without fault. So I hope they take that patch and this case can be closed (maybe with a slight TODO that timer resolution could still be improved upon). Michael
