Re: Flush some statistics within running transactions - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: Flush some statistics within running transactions
Date
Msg-id 202601301556.jgxaz6gj5565@alvherre.pgsql
Whole thread Raw
In response to Re: Flush some statistics within running transactions  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2026-Jan-30, Andres Freund wrote:

> I don't remember. But back then way more complicated things were still running
> in signal handlers, and some signal handlers were capable of interrupting
> other signal handlers. Including doing crazy things like starting transactions
> in signal handlers (e.g. to process notify interrupts), which in turn could
> clear latches. So there was a lot more potential to stomp on each others work.

OK, thanks for clarifying.  I think my proposal of moving the SetLatch()
needs more research, but it's likely the best way to address this
wrinkle.

> WRT the subject of this thread: I hope we aren't just enabling a timer
> to fire once a second forever but only when there actually is
> outstanding work?

I hope so too.  (Just to be clear, I'm not claiming $SUBJECT as its
potential committer, and haven't actually reviewed it.)

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"People get annoyed when you try to debug them."  (Larry Wall)



pgsql-hackers by date:

Previous
From: "zengman"
Date:
Subject: Re: implement CAST(expr AS type FORMAT 'template')
Next
From: Heikki Linnakangas
Date:
Subject: Re: Improvements and refactoring in shmem.c