Re: GNU/Hurd portability patches

Hi,

On Tue, Oct 28, 2025 at 07:00:01AM +0200, Alexander Lakhin wrote:
> One month later, fruitcrow has generated this failure too:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&dt=2025-10-25%2007%3A45%3A03

Thanks for noticing that, I was distracted with pgconf.eu last week...

It hit again today on v17:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&dt=2025-10-30%2011%3A04%3A28
 
> pgsql.build/contrib/pg_stat_statements/regression.diffs
> diff -U3 /home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/expected/entry_timestamp.out /home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/results/entry_timestamp.out
> --- /home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/expected/entry_timestamp.out
> 2025-10-25 08:45:03.000000000 +0100
> +++ /home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/results/entry_timestamp.out
> 2025-10-25 08:57:31.000000000 +0100
> @@ -147,7 +147,7 @@
>  WHERE query LIKE '%STMTTS%';
>   total | minmax_exec_zero | minmax_ts_after_ref | stats_since_after_ref
>  -------+------------------+---------------------+-----------------------
> -     2 |                1 |                   2 |                     0
> +     2 |                2 |                   2 |                     0
>  (1 row)
> 
>  -- Cleanup
> 
> Thus, the "zero time difference" issue in general still exists.

I checked this, if I just run the following excerpt of
entry_timestamp.sql in a tight loop, I get a few (<10) occurrances out
of 10000 iterations where min/max plan time is 0 (or rather
minmax_plan_zero is non-zero):

SELECT pg_stat_statements_reset();
SET pg_stat_statements.track_planning = TRUE;
SELECT 1 AS "STMTTS1";
SELECT
  count(*) as total,
  count(*) FILTER (
    WHERE min_plan_time + max_plan_time = 0
  ) as minmax_plan_zero
FROM pg_stat_statements
WHERE query LIKE '%STMTTS%';

On the assumption that this isn't a general bug, but just a timing issue
(planning 'SELECT 1' isn't complicated), I see two possibilities:

1. Ignore the plan times, and replace SELECT 1 with SELECT
pg_sleep(1e-6), similar to e849bd551. I guess this would reduce test
coverage so likely not be great?

2. Make the query a bit more complicated so that the plan time is likely
to be non-negligable. I actually had to go quite a way to make it pretty
failsafe, the attached made it fail less than 5 times out of 50000
iterations, not sure whether that is acceptable or still considered
flaky?

Any other ideas?


Michael