Date: Thu, 22 Jan 2026 16:45:31 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: 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: <aXJUK90lKXw3wrZn@ip-10-97-1-34.eu-west-3.compute.internal>
References: <aWojE18aF9qj0EPI@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0s9j3x5UPpgaQdDyGA=MNjVEkT73SL7LMoVEKUwiZrVqA@mail.gmail.com>
 <aW4gwqVybB4INCvu@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0s6FkEHFdgKf8J6vueZGwsH+08LvV0YPBXa4Dw_8QgtTw@mail.gmail.com>
 <aXCroXBLiUpxk0Ap@ip-10-97-1-34.eu-west-3.compute.internal>
 <aXFpAisDKy6g_cKx@paquier.xyz>
 <CAA5RZ0sQxAu6bU8wTgvs+aTSvhBcziH9jCJ27aS1hzKsm2kmTQ@mail.gmail.com>
 <CAHGQGwGBkPEK=NpLuk1HSmccu6OA2FYqkkGcA-Hb3WLs6dX=cg@mail.gmail.com>
 <aXHVC6NxERhcThZV@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAHGQGwHttst8tv_WWYNoGGfL1UAq4kiy6dpFXoxEkJwHMS9FtQ@mail.gmail.com>
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/aXJUK90lKXw3wrZn%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

Hi,

On Thu, Jan 22, 2026 at 09:12:18PM +0900, Fujii Masao wrote:
> On Thu, Jan 22, 2026 at 4:43 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> >
> > pgstat_report_anytime_stat() is called with the force parameter set to false,
> > means that the flushes are done with nowait = true means that LWLockConditionalAcquire()
> > is used. In that case, do you still see cases where log_lock_waits messages could
> > be triggered due to the new flush?
> 
> 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.
> 
>     [session 1]
>     create table tbl as select id from generate_series(1, 10) id;
>     begin;
>     select * from tbl where id = 1 for update;
> 
>     [session 2]
>     begin;
>     select * from tbl where id = 1 for update;
> 
> 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.

Regards,

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