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

From Bertrand Drouvot
Subject Re: Flush some statistics within running transactions
Date
Msg-id aYI3TSVkrMMFvnfO@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Flush some statistics within running transactions  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Next
From: Jim Jones
Date:
Subject: Re: Additional message in pg_terminate_backend