Hi all, On Mon, Sep 21, 2026 at 10:45 AM shihao zhong <[email protected]> wrote: > > Hi Bernd, > > Thanks for testing. > > > blks_read differs exactly by 3 and blks_hit by 7 > > I can reproduce this, and it does not need a restart. pg_stat_reset() > clears the database entry and pg_stat_reset_shared() clears the tablespace > entry. If more than a second passes between them, the backend flushes its > pending counts in the gap, and the entry that was reset first keeps them. > Swapping the two resets flips the sign. With both resets in one statement > the numbers always match. > > > there is some skew in blk_read_time and blk_write_time > > Part of it was the second clock read. v7 reuses the time that > pgstat_count_io_op_time() already computed. > > > > one test still checks for >= 0 > > Fixed. > > v7 attached. >
Thank you for the updated patch. I tested the v7 patch and verified that the regression suite completed successfully, with all 239 tests passing, including the stats and tablespace tests. I also performed targeted testing using a dedicated tablespace. The view reported tuple activity for inserts, updates, and deletes, along with nonzero block-write timing when I/O timing was enabled. The checkpoint completed successfully, and the server log showed no errors in the inspected output. After testing, I dropped the test table and tablespace and shut down the separate test server cleanly. One concern is that this targeted workload did not demonstrate nonzero physical-read counters or read timing. Apart from this limitation, I did not observe any functional or regression errors in the tests I performed. Regards, Solai
