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: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Date: 2025-09-30T07:14:14Z
Lists: pgsql-hackers
Hi, On Thu, Feb 27, 2025 at 12:09:46PM +0900, Michael Paquier wrote: > On Wed, Feb 26, 2025 at 05:08:17AM -0500, Andres Freund wrote: > > I think it's also bad that we don't have a solution for 1), even just for > > normal connections. If a backend causes a lot of IO we might want to know > > about that long before the longrunning transaction commits. > > > > I suspect the right design here would be to have a generalized form of the > > timeout mechanism we have for 2). > > > > For that we'd need to make sure that pgstat_report_stat() can be safely called > > inside a transaction. The second part would be to redesign the > > IdleStatsUpdateTimeoutPending mechanism so it is triggered independent of > > idleness, without introducing unacceptable overhead - I think that's doable. > > Agreed that something in the lines of non-transaction update of the > entries could be adapted in some cases, so +1 for the idea. I suspect > that there would be cases where a single stats kind should be able to > handle both transactional and non-transactional flush cases. > Splitting that across two stats kinds would lead to a lot of > duplication. One option could be to use 2 pending lists for the variables stats and 2 flush callbacks for fixed stats. 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