| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Subject: | Re: Flush some statistics within running transactions |
| Date: | 2026-01-30 16:18:17 |
| Message-ID: | 202601301556.jgxaz6gj5565@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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)
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | zengman | 2026-01-30 16:17:22 | Re: implement CAST(expr AS type FORMAT 'template') |