Re: Flush some statistics within running transactions

On Tue, Feb 24, 2026 at 01:55:48PM +0000, Bertrand Drouvot wrote:
> On Tue, Feb 24, 2026 at 08:48:31AM +0900, Michael Paquier wrote:
>> I am concerned about the three additional points/requirements:
>> 1) The need for all processes who want to flush non-transactional
>> stats to set up timeouts, unconditionally, which is what the patch
>> shows with the new InitializeTimeouts() calls added for example for
>> auxiliary processes. This forces the use of SIGALRM in these
>> processes,
>
> Right but they all already call pqsignal(SIGALRM, SIG_IGN), so I'm not sure
> to get the point.

This design requires enabling a new signal with a signal handler in a
lot of processes that did not do that. Enabling timeouts in a bunch
of new processes, while claiming it is fine to do, sounds like
something we should rather be careful about. Are you sure for example
that some of the checkpointer code would not buzz on that, for
example?

At the end, this approach seems too heavy-handed to me. I am also not
entirely convinced that enforcing that unconditionally is the right
thing to do in some cases, either. For the bgwriter, as one example,
we have a WAL report call happening in its main loop, which is quite
good in terms of information frequency obtained.

Wouldn't some case-by-case strategic "anytime" API flush calls make
more sense for some subsystems, rather than relying on a timeout? It
seems rather easy to misuse this design in some bgworker contexts, and
SIGALRM could also be used for a different purpose but we would block
that entirely moving on with future versions?
--
Michael