Re: [BUG]: the walsender does not update its IO statistics until it exits
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-03-13T09:31:29Z
Lists: pgsql-hackers
Attachments
Hi, On Tue, Mar 11, 2025 at 06:10:32AM +0000, Bertrand Drouvot wrote: > WalSndWaitForWal() is being used only for logical walsender. So we'd need to > find another location for the physical walsender case. One option is to keep the > WalSndLoop() location and control the reports frequency. I ended up with an idea in the same vein as your third one, but let's do it in WalSndLoop() instead for both logical and physical walsenders. The idea is to report the stats when the walsender is caught up or has pending data to send. Also, we do flush only periodically (based on PGSTAT_MIN_INTERVAL). Remarks/Questions: 1. maybe relying on PGSTAT_IDLE_INTERVAL would make more sense? In both case PGSTAT_MIN_INTERVAL or PGSTAT_MIN_INTERVAL, I'm not sure there is a need to update the related doc. 2. bonus point to make it here is that we don't need an extra call to GetCurrentTimestamp(). We simply assign the one that is already done to "now". 3. add to use poll_query_until() has I've seen failures on the CI whith this new approach. Also moving the test far away from the stats reset to to minimize the risk of polling for too long. With the attached in place, the number of times the stats are being flushed reduce drastically but still seems enough to get an accurate idea of the walsender IO activity. Thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Commits
-
Flush the IO statistics of active WAL senders more frequently
- e2a82cd23a88 16.9 landed
- 5cbbe70a9cc6 17.5 landed
- 039549d70f6a 18.0 landed
-
Optimize check for pending backend IO stats
- 6d3ea48ff1ae 18.0 landed