Re: Flush some statistics within running transactions

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: 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-26 06:59:28
Message-ID: aXcQ0Bdff5OsUDWY@ip-10-97-1-34.eu-west-3.compute.internal
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Thu, Jan 22, 2026 at 04:45:31PM +0000, Bertrand Drouvot wrote:
> On Thu, Jan 22, 2026 at 09:12:18PM +0900, Fujii Masao wrote:
> >
> > With this setup, the following messages were logged once per second:
> >
> > LOG: process 72199 still waiting for ShareLock on transaction 771
> > after 63034.119 ms
> > DETAIL: Process holding the lock: 72190. Wait queue: 72199.
> >
>
> Thanks!
>
> I see, the WaitLatch() in ProcSleep() is "woken up" every 1s due to the
> enable_timeout_after(ANYTIME_STATS_UPDATE_TIMEOUT,...) being set unconditionally
> in ProcessInterrupts(). We need to be more restrictive as to when to enable the
> timeout, I'll fix in the next version.

The attached, to apply on top of 0001, fix the issue. However it handles only the
WaitLatch in ProcSleep() case and I start to have concern about the others WaitLatch()
that would/could be "woken up" every 1s.

Using disable_timeout() and enable_timeout_after() in WaitEventSetWait() does not
look like a great answer to this concern, so I wonder if we should use a larger
flush frequency instead (as proposed up-thread), thoughts?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
fix_ProcSleep.txt text/plain 1.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-01-26 07:10:03 Re: tablecmds: reject CLUSTER ON for partitioned tables earlier
Previous Message David G. Johnston 2026-01-26 05:38:16 Re: docs: clarify ALTER TABLE behavior on partitioned tables