Re: [BUG]: the walsender does not update its IO statistics until it exits

Поиск
Список
Период
Сортировка
От Bertrand Drouvot
Тема Re: [BUG]: the walsender does not update its IO statistics until it exits
Дата
Msg-id aNuDRhb/UrWQnPfv@ip-10-97-1-34.eu-west-3.compute.internal
обсуждение исходный текст
Ответ на Re: [BUG]: the walsender does not update its IO statistics until it exits  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: [BUG]: the walsender does not update its IO statistics until it exits
Список pgsql-hackers
Hi,

On Thu, Feb 27, 2025 at 12:09:46PM +0900, Michael Paquier wrote:
> On Wed, Feb 26, 2025 at 05:08:17AM -0500, Andres Freund wrote:
> > I think it's also bad that we don't have a solution for 1), even just for
> > normal connections. If a backend causes a lot of IO we might want to know
> > about that long before the longrunning transaction commits.
> > 
> > I suspect the right design here would be to have a generalized form of the
> > timeout mechanism we have for 2).
> > 
> > For that we'd need to make sure that pgstat_report_stat() can be safely called
> > inside a transaction.  The second part would be to redesign the
> > IdleStatsUpdateTimeoutPending mechanism so it is triggered independent of
> > idleness, without introducing unacceptable overhead - I think that's doable.
> 
> Agreed that something in the lines of non-transaction update of the
> entries could be adapted in some cases, so +1 for the idea.  I suspect
> that there would be cases where a single stats kind should be able to
> handle both transactional and non-transactional flush cases.
> Splitting that across two stats kinds would lead to a lot of
> duplication.

One option could be to use 2 pending lists for the variables stats and 2 flush
callbacks for fixed stats. Thoughts?

Regards,

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



В списке pgsql-hackers по дате отправления: