Feedback-ID: ie3de48e3:Fastmail
Date: Fri, 30 Jan 2026 10:46:11 +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: <202601300940.gzzbe57cdvny@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHGQGwHttst8tv_WWYNoGGfL1UAq4kiy6dpFXoxEkJwHMS9FtQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/202601300940.gzzbe57cdvny%40alvherre.pgsql>
Precedence: bulk

On 2026-Jan-22, Fujii Masao wrote:

> I haven't read the patch in detail yet, but after applying patch 0001 and
> causing a lock wait (for example, using the steps below), I observed that
> log_lock_waits messages are emitted every second.

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?

I tested this theory quickly by removing the SetLatch from
IdleStatsUpdateTimeoutHandler() and rerunning the tests.  (This one
chosen because it has highest coverage per [2]).  Everything passed,
though of course this is probably not proof enough.

Maybe we're just cargo-culting these SetLatch() calls?

[1] https://postgr.es/m/aXJUK90lKXw3wrZn@ip-10-97-1-34.eu-west-3.compute.internal
[2] https://coverage.postgresql.org/src/backend/utils/init/postinit.c.gcov.html

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Right now the sectors on the hard disk run clockwise, but I heard a rumor that
you can squeeze 0.2% more throughput by running them counterclockwise.
It's worth the effort. Recommended."  (Gerry Pourwelle)