Re: per backend I/O statistics - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Re: per backend I/O statistics
Date
Msg-id 6143ab0a-9e88-4790-8d9d-50ba45657761@gmail.com
Whole thread Raw
In response to Re: per backend I/O statistics  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
Hello Michael,

19.12.2024 06:21, Michael Paquier wrote:
Fixed that, bumped the two version counters, and done.

Could you, please, look at recent failures produced by grassquit (which
has fsync = on in it's config), on an added test case? For instance, [1]:
--- /home/bf/bf-build/grassquit/HEAD/pgsql/src/test/regress/expected/stats.out    2024-12-19 04:44:08.779311933 +0000
+++ /home/bf/bf-build/grassquit/HEAD/pgsql.build/testrun/recovery/027_stream_regress/data/results/stats.out    2024-12-19 16:37:41.351784840 +0000
@@ -1333,7 +1333,7 @@
       AND :my_io_sum_shared_after_fsyncs= 0);
  ?column?
 ----------
- t
+ f
 (1 row)
 
The complete query is:
SELECT current_setting('fsync') = 'off'
  OR (:my_io_sum_shared_after_fsyncs = :my_io_sum_shared_before_fsyncs
      AND :my_io_sum_shared_after_fsyncs= 0);

And the corresponding query in 027_stream_regress_primary.log is:
2024-12-19 16:37:39.907 UTC [4027467][client backend][15/1980:0] LOG:  statement: SELECT current_setting('fsync') = 'off'
      OR (1 = 1
          AND 1= 0);

(I can reproduce this locally with an asan-enabled build too.)

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=grassquit&dt=2024-12-19%2016%3A28%3A58

Best regards,
Alexander

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Skip collecting decoded changes of already-aborted transactions
Next
From: Corey Huinker
Date:
Subject: Re: Statistics Import and Export