On Wed, Feb 05, 2025 at 09:52:14PM -0500, Tom Lane wrote: > Michael Paquier <mich...@paquier.xyz> writes: > Yeah, if we want to assume we can see stats counts left over from > initdb, we have to put this in a TAP test, though I dunno if that is > the most appropriate one.
A second option I can think of for the reads is a SQL query in pg_walinspect. We are sure that we have a xlogreader context there, forcing reads. Anyway, I would just stick all that to TAP, like the attached in 027, where we would rely on the startup process to read data, and the checkpointer to initialize a segment for the primary. Perhaps not the best position, but we already have similar queries in this test, and these two are cheap. Thoughts about the attached? > Now that I've looked at the tests a bit, I'm also distressed > by this test pattern: > > SELECT stats_reset AS slru_commit_ts_reset_ts FROM pg_stat_slru WHERE name = > 'commit_timestamp' \gset > SELECT pg_stat_reset_slru(); > SELECT stats_reset > :'slru_commit_ts_reset_ts'::timestamptz FROM > pg_stat_slru WHERE name = 'commit_timestamp'; > > This assumes that the execution time of pg_stat_reset_slru() is more > than the system clock resolution. I won't be surprised to see that > fail in the future. We did discover recently that gettimeofday is > good to the microsecond on most modern platforms [1], but it won't > get any better than that, while our machines keep getting faster. > Just for reference, on my hardly-bleeding-edge-anymore workstation: Hmm. Interesting. -- Michael
diff --git a/src/test/recovery/t/027_stream_regress.pl b/src/test/recovery/t/027_stream_regress.pl
index bab7b28084b..a04ecc4d2db 100644
--- a/src/test/recovery/t/027_stream_regress.pl
+++ b/src/test/recovery/t/027_stream_regress.pl
@@ -63,6 +63,26 @@ $node_standby_1->append_conf('postgresql.conf',
'max_standby_streaming_delay = 600s');
$node_standby_1->start;
+# Check some WAL statistics. The standby should have done WAL reads in
+# the startup process when starting, and the primary WAL some writes with
+# its checkpointer.
+my $result = $node_primary->safe_psql(
+ 'postgres',
+ qq{SELECT object, context, writes > 0 AS writes_done
+ FROM pg_stat_io
+ WHERE context = 'init' AND
+ object = 'wal' AND
+ backend_type = 'checkpointer'});
+is($result, qq(wal|init|t), 'check contents of WAL stats on primary');
+$result = $node_standby_1->safe_psql(
+ 'postgres',
+ qq{SELECT object, context, reads > 0 AS reads_done
+ FROM pg_stat_io
+ WHERE context = 'normal' AND
+ object = 'wal' AND
+ backend_type = 'startup'});
+is($result, qq(wal|normal|t), 'check contents of WAL stats on standby');
+
my $dlpath = dirname($ENV{REGRESS_SHLIB});
my $outputdir = $PostgreSQL::Test::Utils::tmp_check;
@@ -163,7 +183,7 @@ $node_primary->safe_psql('postgres', 'CREATE EXTENSION pg_stat_statements');
# This gathers data based on the first characters for some common query types,
# checking that reports are generated for SELECT, DMLs, and DDL queries with
# CREATE.
-my $result = $node_primary->safe_psql(
+$result = $node_primary->safe_psql(
'postgres',
qq{WITH select_stats AS
(SELECT upper(substr(query, 1, 6)) AS select_query
diff --git a/src/test/regress/expected/stats.out b/src/test/regress/expected/stats.out
index 9a02481ee7e..7d91f047bb3 100644
--- a/src/test/regress/expected/stats.out
+++ b/src/test/regress/expected/stats.out
@@ -862,33 +862,6 @@ WHERE pg_stat_get_backend_pid(beid) = pg_backend_pid();
t
(1 row)
--- Test pg_stat_io for WAL in an init context, that should do writes
--- and syncs.
-SELECT sum(writes) AS writes, sum(fsyncs) AS fsyncs
- FROM pg_stat_io
- WHERE context = 'init' AND object = 'wal' \gset io_sum_wal_init_
-SELECT :io_sum_wal_init_writes > 0;
- ?column?
-----------
- t
-(1 row)
-
-SELECT current_setting('fsync') = 'off'
- OR :io_sum_wal_init_fsyncs > 0;
- ?column?
-----------
- t
-(1 row)
-
--- Test pg_stat_io for WAL in a normal context, that should do reads as well.
-SELECT SUM(reads) > 0
- FROM pg_stat_io
- WHERE context = 'normal' AND object = 'wal';
- ?column?
-----------
- t
-(1 row)
-
-----
-- Test that resetting stats works for reset timestamp
-----
diff --git a/src/test/regress/sql/stats.sql b/src/test/regress/sql/stats.sql
index 901e7bd56e3..11628ebc8a1 100644
--- a/src/test/regress/sql/stats.sql
+++ b/src/test/regress/sql/stats.sql
@@ -442,20 +442,6 @@ SELECT (current_schemas(true))[1] = ('pg_temp_' || beid::text) AS match
FROM pg_stat_get_backend_idset() beid
WHERE pg_stat_get_backend_pid(beid) = pg_backend_pid();
--- Test pg_stat_io for WAL in an init context, that should do writes
--- and syncs.
-SELECT sum(writes) AS writes, sum(fsyncs) AS fsyncs
- FROM pg_stat_io
- WHERE context = 'init' AND object = 'wal' \gset io_sum_wal_init_
-SELECT :io_sum_wal_init_writes > 0;
-SELECT current_setting('fsync') = 'off'
- OR :io_sum_wal_init_fsyncs > 0;
-
--- Test pg_stat_io for WAL in a normal context, that should do reads as well.
-SELECT SUM(reads) > 0
- FROM pg_stat_io
- WHERE context = 'normal' AND object = 'wal';
-
-----
-- Test that resetting stats works for reset timestamp
-----
signature.asc
Description: PGP signature
