Re: Flush some statistics within running transactions

On Thu, Jan 22, 2026 at 4:43 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Thu, Jan 22, 2026 at 10:56:48AM +0900, Fujii Masao wrote:
> > On Thu, Jan 22, 2026 at 10:41 AM Sami Imseih <samimseih(at)gmail(dot)com> wrote:
> > >
> > > Sure, Bertrand mentioned early in the thread that the anytime flushes
> > > could be made configurable. Perhaps that is a good idea where we can
> > > default with something large like 10s intervals for anytime flushes, but allow
> > > the user to configure a more frequent flushes ( although I would think
> > > that 1 sec is the minimum we should allow ).
> >
> > +1 on adding an option to control the interval. With a fixed interval
> > (for example, 1s), log_lock_waits messages could be emitted that frequently,
> > which may be annoying for some users.
> >
> > Of course, it would be even better if these periodic wakeups did not trigger
> > log_lock_waits messages at all, though.
>
> 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.

Regards,

--
Fujii Masao