From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Is a pg_stat_force_next_flush() call sufficient for regression tests? |
Date: | 2023-07-03 13:45:52 |
Message-ID: | 022124fb-70c4-e59f-029e-b752853f7c84@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I noticed eelpout failed with this in stats.sql, in the pg_stat_io tests
added a couple months ago [1]:
@@ -1415,7 +1415,7 @@
:io_sum_vac_strategy_after_reuses >
:io_sum_vac_strategy_before_reuses;
?column? | ?column?
----------+----------
- t | t
+ t | f
(1 row)
The failure seems completely unrelated to the new commit, so this seems
like some randomness / timing issue. The failing bit does this:
----------------------------
VACUUM (PARALLEL 0, BUFFER_USAGE_LIMIT 128) test_io_vac_strategy;
SELECT pg_stat_force_next_flush();
SELECT sum(reuses) AS reuses, sum(reads) AS reads
FROM pg_stat_io WHERE context = 'vacuum' \gset io_sum_vac_strategy_after_
SELECT :io_sum_vac_strategy_after_reads > :io_sum_vac_strategy_before_reads,
:io_sum_vac_strategy_after_reuses >
:io_sum_vac_strategy_before_reuses;
----------------------------
So I'm wondering if pg_stat_force_next_flush() is enough - AFAICS this
only sets some flag for the *next* pgstat_report_stat() call, but how do
we know that happens before the query execution?
Shouldn't there be something like pg_stat_flush() that actually does the
flushing, instead of just setting the flag?
regards
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=eelpout&dt=2023-07-03%2011%3A09%3A13
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2023-07-03 13:57:50 | Re: logicalrep_message_type throws an error |
Previous Message | Daniel Gustafsson | 2023-07-03 13:42:44 | Re: Add support for AT LOCAL |