Feedback-ID: ie3de48e3:Fastmail
Date: Fri, 30 Jan 2026 13:42:36 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	Sami Imseih <samimseih@gmail.com>, Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers@lists.postgresql.org, Zsolt Parragi <zsolt.parragi@percona.com>
Subject: Re: Flush some statistics within running transactions
Message-ID: <202601301136.kvw5jklzhkru@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <202601300940.gzzbe57cdvny@alvherre.pgsql>
Archived-At: 
 <https://www.postgresql.org/message-id/202601301136.kvw5jklzhkru%40alvherre.pgsql>
Precedence: bulk

On 2026-Jan-30, Álvaro Herrera wrote:

> Interesting.  Bertrand asked me about this.  He says[1] he diagnosed this
> down to SetLatch being called immediately after the handler runs, and I
> wonder if it's correct that other timeout handler functions used for
> RegisterTimeout are doing SetLatch().  The SIGALRM handler
> handle_sig_alarm() that calls the specific handler function already has
> a SetLatch call, so why do we need another one here?

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:

void
CheckDeadLockAlert(void)
{
    int         save_errno = errno;

    got_deadlock_timeout = true;

    /*
     * Have to set the latch again, even if handle_sig_alarm already did. Back
     * then got_deadlock_timeout wasn't yet set... It's unlikely that this
     * ever would be a problem, but setting a set latch again is cheap.
     */
    SetLatch(MyLatch);
    errno = save_errno;
}


I wonder if it would work to move the SetLatch() that's currently at the
top of handle_sig_alarm() to the bottom, after we have called all the
specific handlers, and remove the ones that are there.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/