Re: Flush some statistics within running transactions

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: 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 09:46:11
Message-ID: 202601300940.gzzbe57cdvny@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2026-01-30 09:48:36 Re: Improve pg_sync_replication_slots() to wait for primary to advance
Previous Message vignesh C 2026-01-30 09:34:48 Re: [Proposal] Adding Log File Capability to pg_createsubscriber