On Thu, Feb 19, 2026 at 08:01:36AM +0000, Bertrand Drouvot wrote: > On Thu, Feb 19, 2026 at 12:58:12PM +0900, Michael Paquier wrote: >> 2) The timeout requirement itself, relying on a timeout threshold >> controlled by a backend-side configuration. > > What are you concerns with this?
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, with a new handler, and feels like a requirement too heavy for the sake of some stats flushes. This requires an extra unconditional RegisterTimeout(), as well. 2) The need for all the stats to call pgstat_schedule_anytime_update() in strategical places. This is less of a burden compared to 1), but this leads to more complications in these code paths with the coding requirements, especially for custom stats kinds. 3) Enforcing a flush timeout unconditionally. One thing that slightly concerns me here is that it seems easier to misuse compared to a client-based facility, where a too aggressive setup could stress more the server-side pgstats. It is true that the client-side could be misused too. My main worries are mainly around 1), I guess, with the new SIGALRM handler requirements for all auxiliary processes. Using a procsignal path would allow us to rely on a solution that has the same flexibility, combined with strategic additional flush calls that we could spread depending on requirements we want to enforce in some processes, like in the WAL sender, or perhaps the checkpointer. That seems more careful in the long-run, and this can rely on the interrupt processing for the job. The addition of the property to track if a stats kind of OK to flush outside a transaction boundary is also critical to have, of course. I am sold to the point point of the design about this new property tracked in the stats kind meta-data. >> With that in mind, wouldn't it be simpler if we introduced an API that >> could be used from client applications instead, in a model similar >> what we do for procsignal.c/h? > > That's another angle to look at it but I think that giving this > responsability to > the clients would not solve the concerns we had in [1] (that led to > 039549d70f6 > and to this thread). It seems to me that a solution/design that does not allow > us to "revert" 039549d70f6 does not suit our needs. Thoughts? 039549d70f6 goes in line with the "client" prospective, where I would like to think that strategic flush calls are more flexible. > Yeah, after our off-list discussion yesterday, I tried to implement the same > trick that f1e251be80a has done with injection points (nice trick by the > way!), > but that led to: In this case, avoiding an injpoint allocation in a critical section would be a two-step process: - INJECTION_POINT_LOAD(), before the critical section, to warm up the cache and do all the allocations. - INJECTION_POINT_CACHED() with IS_INJECTION_POINT_ATTACHED() (optional), to run the point, in the critical section. This tactic is already in use in the tree. You would have to use a more complicated scheme to make sure that the wait machinery is initialized when using it in a critical section, but that can be worked around as well. See my "state-of-the-art" work of 15f68cebdcec, which, well, happens to work. Not really the best work ever with two points, but it works for this purpose. :D -- Michael
signature.asc
Description: PGP signature
