Re: Statistics updates is delayed when using `commit and chain` - Mailing list pgsql-bugs

From Andres Freund
Subject Re: Statistics updates is delayed when using `commit and chain`
Date
Msg-id 20220801171051.vxnit2t6soddaquh@awork3.anarazel.de
Whole thread Raw
In response to Re: Statistics updates is delayed when using `commit and chain`  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Statistics updates is delayed when using `commit and chain`
List pgsql-bugs
Hi,

On 2022-08-01 12:43:23 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2022-08-01 12:25:58 -0400, Tom Lane wrote:
> >> What I suggested a few days ago is that it should be in CommitTransaction.
> 
> > I wonder how we'd best deal with the idle timer if we go for that. That only
> > makes sense in some contexts (normal backends), but not others (everything
> > else).
> 
> Yeah.  I think we'd need to get rid of the "bool force" argument
> of pgstat_report_stat, and instead have it manage things internally
> based on understanding whether the current process uses a reporting
> timeout timer or not (if not, always send the report right away).
> That seems like it'd be more robust than the current mechanism anyway,
> as we're currently relying on every call site to get that right.

It's not as simple as looking at the backend type, I think. We'd not want to
enable a timer in the commit-and-chain context, even in a normal backend -
there's no chance we'll go idle.

I wonder if it was the wrong call to use timers for IdleSessionTimeout,
IdleInTransactionSessionTimeout and pgstats. We always use nonblocking socket
IO these days, so perhaps we should instead just compute a relevant timeout
for the WaitEventSetWait() call?

Greetings,

Andres Freund



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Statistics updates is delayed when using `commit and chain`
Next
From: Tom Lane
Date:
Subject: Re: Statistics updates is delayed when using `commit and chain`