Add regression test checking combinations of (object,backend_type,context) in pg_stat_io
Hi all,
While working on I/O statistics, I have noticed that it is not
complicated to break the set of rows returned by pg_stat_io if one is
not careful when updating pgstat_tracks_io_object().
Attached is a patch that I've found useful as a sanity check,
returning all the combinations supported for BackendType, IOContext
and IOObject, so as it is easily possible to evaluate if the
information returned is relevant.
Thoughts?
--
Michael
Attachments:
statio-regress-check.patchtext/x-diff; charset=us-asciiDownload
diff --git a/src/test/regress/expected/stats.out b/src/test/regress/expected/stats.out
index 093e6368dbbe..8a28bc0ed623 100644
--- a/src/test/regress/expected/stats.out
+++ b/src/test/regress/expected/stats.out
@@ -11,6 +11,83 @@ SHOW track_counts; -- must be on
on
(1 row)
+-- List of backend types, context and objects tracked in pg_stat_io.
+\a
+SELECT backend_type, object, context FROM pg_stat_io ORDER BY 1, 2, 3;
+backend_type|object|context
+autovacuum launcher|relation|bulkread
+autovacuum launcher|relation|init
+autovacuum launcher|relation|normal
+autovacuum launcher|wal|init
+autovacuum launcher|wal|normal
+autovacuum worker|relation|bulkread
+autovacuum worker|relation|init
+autovacuum worker|relation|normal
+autovacuum worker|relation|vacuum
+autovacuum worker|wal|init
+autovacuum worker|wal|normal
+background worker|relation|bulkread
+background worker|relation|bulkwrite
+background worker|relation|init
+background worker|relation|normal
+background worker|relation|vacuum
+background worker|temp relation|normal
+background worker|wal|init
+background worker|wal|normal
+background writer|relation|init
+background writer|relation|normal
+background writer|wal|init
+background writer|wal|normal
+checkpointer|relation|init
+checkpointer|relation|normal
+checkpointer|wal|init
+checkpointer|wal|normal
+client backend|relation|bulkread
+client backend|relation|bulkwrite
+client backend|relation|init
+client backend|relation|normal
+client backend|relation|vacuum
+client backend|temp relation|normal
+client backend|wal|init
+client backend|wal|normal
+slotsync worker|relation|bulkread
+slotsync worker|relation|bulkwrite
+slotsync worker|relation|init
+slotsync worker|relation|normal
+slotsync worker|relation|vacuum
+slotsync worker|temp relation|normal
+slotsync worker|wal|init
+slotsync worker|wal|normal
+standalone backend|relation|bulkread
+standalone backend|relation|bulkwrite
+standalone backend|relation|init
+standalone backend|relation|normal
+standalone backend|relation|vacuum
+standalone backend|wal|init
+standalone backend|wal|normal
+startup|relation|bulkread
+startup|relation|bulkwrite
+startup|relation|init
+startup|relation|normal
+startup|relation|vacuum
+startup|wal|init
+startup|wal|normal
+walreceiver|wal|init
+walreceiver|wal|normal
+walsender|relation|bulkread
+walsender|relation|bulkwrite
+walsender|relation|init
+walsender|relation|normal
+walsender|relation|vacuum
+walsender|temp relation|normal
+walsender|wal|init
+walsender|wal|normal
+walsummarizer|wal|init
+walsummarizer|wal|normal
+walwriter|wal|init
+walwriter|wal|normal
+(71 rows)
+\a
-- ensure that both seqscan and indexscan plans are allowed
SET enable_seqscan TO on;
SET enable_indexscan TO on;
diff --git a/src/test/regress/sql/stats.sql b/src/test/regress/sql/stats.sql
index 0a44e14d9f4a..141e2073e8cb 100644
--- a/src/test/regress/sql/stats.sql
+++ b/src/test/regress/sql/stats.sql
@@ -8,6 +8,11 @@
-- conditio sine qua non
SHOW track_counts; -- must be on
+-- List of backend types, context and objects tracked in pg_stat_io.
+\a
+SELECT backend_type, object, context FROM pg_stat_io ORDER BY 1, 2, 3;
+\a
+
-- ensure that both seqscan and indexscan plans are allowed
SET enable_seqscan TO on;
SET enable_indexscan TO on;
Hi,
On Wed, Mar 05, 2025 at 11:05:48AM +0900, Michael Paquier wrote:
Hi all,
While working on I/O statistics, I have noticed that it is not
complicated to break the set of rows returned by pg_stat_io if one is
not careful when updating pgstat_tracks_io_object().Attached is a patch that I've found useful as a sanity check,
returning all the combinations supported for BackendType, IOContext
and IOObject, so as it is easily possible to evaluate if the
information returned is relevant.Thoughts?
That would mean changing the test each time pgstat_tracks_io_object() is
modified in such a way that the output is changed. That's a good thing as
the writer will need to double check if the new output makes sense according
to his changes. So I don't see any reason not to add this test.
+SELECT backend_type, object, context FROM pg_stat_io ORDER BY 1, 2, 3;
What about adding some extra paranoia like?
SELECT backend_type, object, context FROM pg_stat_io ORDER BY backend_type, object, context COLLATE "C";
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On Wed, Mar 05, 2025 at 07:34:16AM +0000, Bertrand Drouvot wrote:
That would mean changing the test each time pgstat_tracks_io_object() is
modified in such a way that the output is changed. That's a good thing as
the writer will need to double check if the new output makes sense according
to his changes. So I don't see any reason not to add this test.
Thanks for the review.
What about adding some extra paranoia like?
SELECT backend_type, object, context FROM pg_stat_io ORDER BY
backend_type, object, context COLLATE "C";
Why not, to force the ordering.
--
Michael
On Wed, Mar 05, 2025 at 09:19:16PM +0900, Michael Paquier wrote:
On Wed, Mar 05, 2025 at 07:34:16AM +0000, Bertrand Drouvot wrote:
What about adding some extra paranoia like?
SELECT backend_type, object, context FROM pg_stat_io ORDER BY
backend_type, object, context COLLATE "C";Why not, to force the ordering.
For the sake of the archives. As 8b532771a099 has proved, this has
required two more COLLATE clauses in the query to force a stable
output, but we are in the clear now.
--
Michael