Re: GNU/Hurd portability patches - Mailing list pgsql-hackers

Michael Banck <mbanck@gmx.net> writes:
> This is the pg_test_timing output on my hurd-i386 VM with
> pg_test_timing from HEAD:

Ask and ye shall receive ... sorry for not reading the whole thread.

> I wonder what is going on here, was that a fluke or is that not related
> to the stats isolation test failure after all? Anybody else tried the
> updated pg_test_timing on Apple hardware and could possibly run the tt.c
> test case from Alexander?

Yeah, I see zero-ns outputs on a couple different Apple M-series
machines.  This is the output on the M4 Mini that runs the sifaka
and indri BF animals:

$ pg_test_timing
Testing timing overhead for 3 seconds.
Average loop time including overhead: 17.22 ns
Histogram of timing durations:
   <= ns   % of total  running %      count
       0      58.8235    58.8235  102495613
       1       0.0000    58.8235          0
       3       0.0000    58.8235          0
       7       0.0000    58.8235          0
      15       0.0000    58.8235          0
      31       0.0000    58.8235          0
      63      41.1229    99.9464   71653499
     127       0.0502    99.9966      87421
     255       0.0026    99.9992       4522
     511       0.0000    99.9992         56
    1023       0.0001    99.9993        117
    2047       0.0001    99.9994        164
    4095       0.0003    99.9997        558
    8191       0.0003   100.0000        501
   16383       0.0000   100.0000         50
   32767       0.0000   100.0000         17
   65535       0.0000   100.0000          0
  131071       0.0000   100.0000          1

Observed timing durations up to 99.9900%:
      ns   % of total  running %      count
       0      58.8235    58.8235  102495613
      41      13.7077    72.5313   23884717
      42      27.4151    99.9464   47768782
      83       0.0277    99.9741      48304
      84       0.0140    99.9881      24425
     125       0.0084    99.9966      14692
...
  107083       0.0000   100.0000          1

Those animals are not showing failures, so we can't blame
"clock didn't advance" as a problem in itself.  However,
the thing that jumps out at me from your results is that
the clock resolution seems to be only 3 to 4 us on Hurd:

> Histogram of timing durations:
>    <= ns   % of total  running %      count
>        0       0,0510     0,0510        122
>        1       0,0000     0,0510          0
>        3       0,0000     0,0510          0
>        7       0,0000     0,0510          0
>       15       0,0000     0,0510          0
>       31       0,0000     0,0510          0
>       63       0,0000     0,0510          0
>      127       0,0000     0,0510          0
>      255       0,0000     0,0510          0
>      511       0,0000     0,0510          0
>     1023       0,0004     0,0514          1
>     2047       0,0000     0,0514          0
>     4095      98,9320    98,9834     236681
>     8191       0,8845    99,8679       2116

It seems plausible that the execution time of the stats
test's function-under-test is so short that it sometimes
doesn't register as more than zero on a machine with poor
clock resolution.  It looks like that test only calls the
test function once or twice before checking that it's
accumulated some runtime, and the test function is nothing
more than

    CREATE FUNCTION test_stat_func() RETURNS VOID LANGUAGE plpgsql AS $$BEGIN END;$$;

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.

            regards, tom lane