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. -- Michael
signature.asc
Description: PGP signature
