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