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
