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