Re: Flush some statistics within running transactions
| От | Bertrand Drouvot |
|---|---|
| Тема | Re: Flush some statistics within running transactions |
| Дата | |
| Msg-id | aYI3TSVkrMMFvnfO@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
| Ответ на | Re: Flush some statistics within running transactions (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
Hi, On Tue, Feb 03, 2026 at 12:09:31PM -0500, Andres Freund wrote: > 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.) > > > 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). > Yeah, this was just a finding while diagnosing the ProcSleep() "issue". This discussion is not relevant in this thread anymore (specially since v5 where the design changed in such a way that the ProcSleep() "issue" does not appear anymore). We could open a dedicated thread if we think that's worth continuing the discussion about removing the SetLatch() in those handlers (but they are probably harmless to keep afterall). Thanks to you and Álvaro for having shared your thoughts on it. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: