Re: Flush some statistics within running transactions

Hi,

On 2026-02-03 06:19:13 +0000, Bertrand Drouvot wrote:
> On Fri, Jan 30, 2026 at 03:37:57PM +0100, Álvaro Herrera wrote:
> > (Though to be honest, it's not clear to me why it would matter at which
> > point in handle_sig_alarm we call SetLatch relative to the variables
> > being set, given that these variables are only going to matter once the
> > signal handler returns to the original code and the next
> > CHECK_FOR_INTERRUPTS is hit.)
> 
> Yeah, I think that we could keep the SetLatch() at the top of handle_sig_alarm().

Why at the top, rather than at the bottom?  I don't think / I hope today's
signal handlers rely on it, but in the past we had cases where some signal
handlers ran code that could lead to a ResetLatch() being done.


Why does it matter for your patch whether SetLatch() is done multiple times as
part of various timeout handlers? I don't see how repeated SetLatch() calls
could trigger more interference with ProcSleep()? Once the latch is set it is
set (and indeed SetLatch() just returns immediately if it already is set).


> My understanding is that the signal handler runs to completion without being interrupted
> by the code it interrupted.

Right. But they can, on some platforms at least, be interrupted by *other*
signal handlers. I don't see any reason to believe that is not happening at
the moment.


> Out of curiosity, I also remove the ones in handlers (and keep the one in handle_sig_alarm()
> at the top), and everything seems to work fine:
>
> https://cirrus-ci.com/build/6277169619402752

That doesn't tell you very much, I think. Our coverage of the relevant edge
cases isn't that good, I think.

Greetings,

Andres Freund