Re: Flush some statistics within running transactions

Hi,

On Tue, Feb 24, 2026 at 08:48:31AM +0900, Michael Paquier wrote:
> 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,

Right but they all already call pqsignal(SIGALRM, SIG_IGN), so I'm not sure
to get the point.

> This requires an extra unconditional RegisterTimeout(), as well.

Yes, I'm not clear why that's an issue though.

> 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.

I think that's solved with Sami's proposal for variable stats kind (to flush or
schedule when the session is idle).

> 3) Enforcing a flush timeout unconditionally.

What do you mean? It's done only if there is things to flush.

> 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.

I see, but we know they'll have to flush IO or WAL stats at some point so
enabling the timeout for those look ok.

> 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.

Great!

> 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.

Oh okay, thanks for the explanation!

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com