Re: Flush some statistics within running transactions

Hi,

On Fri, Jan 30, 2026 at 03:37:57PM +0100, Álvaro Herrera wrote:
> On 2026-Jan-30, Álvaro Herrera wrote:
> 
> > So apparently the first function to do this in postinit.c was added by
> > commit c6dda1f48e57 -- and apparently it was mimicking
> > CheckDeadLockAlert(), which at this time looked like this:
> 
> I'm now wondering if CheckDeadLockAlert() really needed to have this in
> the first place, or it was just an exercise in paranoia ... it was added
> by commit 6753333f55e1, with the discussion in [1], and it's not clear
> to me that there was any theoretical or experimental evidence that it
> was necessary; the thread didn't discuss it, and the commit message
> doesn't either.  Added Andres to CC as committer to this thread, maybe
> he remembers.
> 
> [1] https://www.postgresql.org/message-id/flat/20150115020335.GZ5245%40awork2.anarazel.de
> 
> Just for laughs I moved the SetLatch call in handle_sig_alarm() to the
> bottom, and remove the ones in handlers, on the theory that by the time
> the SetLatch call is reached, all the handlers have already run and thus
> the flag variables are set.  Everything seems to continue to work:
> https://cirrus-ci.com/build/5758839359799296

Thanks for having looked at this!

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

My understanding is that the signal handler runs to completion without being interrupted
by the code it interrupted. So, by the time the interrupted code (like epoll_wait())
resumes and can check the latch, the entire handler has finished. So, if my understanding
is correct, having SetLatch() at the top or the bottom should not change anything (
as long as we don't have nested signal handlers).

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

Regards,

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