Re: Statistics updates is delayed when using `commit and chain`
| От | Andres Freund |
|---|---|
| Тема | Re: Statistics updates is delayed when using `commit and chain` |
| Дата | |
| Msg-id | 20220801171051.vxnit2t6soddaquh@awork3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: Statistics updates is delayed when using `commit and chain` (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Statistics updates is delayed when using `commit and chain`
|
| Список | 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 по дате отправления: