Message-ID: <6903848e.5d0a0220.13f62d.b8b9@mx.google.com>
Sender: Michael Banck <mbanck@gmail.com>
Date: Thu, 30 Oct 2025 16:30:22 +0100
From: Michael Banck <mbanck@gmx.net>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers@lists.postgresql.org,
	Thomas Munro <thomas.munro@gmail.com>
Subject: Re: GNU/Hurd portability patches
References: <283c3d69-ef32-4391-9ea3-68e47c9dea31@gmail.com>
 <aNMtzyqgin8I4r5H@paquier.xyz>
 <68d3a0a0.050a0220.167290.bcf3@mx.google.com>
 <68d3cbe8.5d0a0220.65f10.da5f@mx.google.com>
 <3314741.1758724126@sss.pgh.pa.us>
 <68d413a3.a70a0220.24c74c.8be9@mx.google.com>
 <a1d9eab8-7063-4eb1-a922-f54923029c52@gmail.com>
 <68d460fe.170a0220.3c484.0a59@mx.google.com>
 <4557939c-01e1-47b6-8b79-bdfc74882275@gmail.com>
 <9e9bacfa-37c6-48e9-9a25-741c79a1d5e5@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="eRtJSFbw+EEWtPj3"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9e9bacfa-37c6-48e9-9a25-741c79a1d5e5@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/6903848e.5d0a0220.13f62d.b8b9%40mx.google.com>
Precedence: bulk


--eRtJSFbw+EEWtPj3
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

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

--eRtJSFbw+EEWtPj3
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="0001-Make-pg_stat_statement-s-entry_timestamp-test-less-f.patch"