Flush the IO statistics of active WAL senders more frequently
authorMichael Paquier <michael@paquier.xyz>
Mon, 7 Apr 2025 22:58:47 +0000 (07:58 +0900)
committerMichael Paquier <michael@paquier.xyz>
Mon, 7 Apr 2025 22:58:47 +0000 (07:58 +0900)
commit5cbbe70a9cc6a9d8b7ed583cf66657be8ace0eaa
tree30dfa2421da5e6f8ba347aae18d4b0dfd206fa31
parent4c1d853fd8c7ed832a231699512dc3f0fb6376fd
Flush the IO statistics of active WAL senders more frequently

WAL senders do not flush their statistics until they exit, limiting the
monitoring possible for live processes.  This is penalizing when WAL
senders are running for a long time, like in streaming or logical
replication setups, because it is not possible to know the amount of IO
they generate while running.

This commit makes WAL senders more aggressive with their statistics
flush, using an internal of 1 second, with the flush timing calculated
based on the existing GetCurrentTimestamp() done before the sleeps done
to wait for some activity.  Note that the sleep done for logical and
physical WAL senders happens in two different code paths, so the stats
flushes need to happen in these two places.

One test is added for the physical WAL sender case, and one for the
logical WAL sender case.  This can be done in a stable fashion by
relying on the WAL generated by the TAP tests in combination with a
stats reset while a server is running, but only on HEAD as WAL data has
been added to pg_stat_io in a051e71e28a1.

This issue exists since a9c70b46dbe and the introduction of pg_stat_io,
so backpatch down to v16.

Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: vignesh C <vignesh21@gmail.com>
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>
Discussion: https://postgr.es/m/Z73IsKBceoVd4t55@ip-10-97-1-34.eu-west-3.compute.internal
Backpatch-through: 16
src/backend/replication/walsender.c