Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system
Дата
Msg-id 5124000F.6090704@fuzzy.cz
обсуждение исходный текст
Ответ на Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On 19.2.2013 23:31, Alvaro Herrera wrote:> Tomas Vondra wrote:
> 
>> AFAIK the stats remain the same within a transaction, and as a
>> function runs within a transaction, it will either get new data on
>> the first iteration, or it will run all 300 of them. I've checked
>> several buildfarm members and I'm yet to see a single duration
>> between 12ms and 30sec.
> 
> No, there's a call to pg_stat_clear_snapshot() that takes care of
> that.

Aha! Missed that for some reason. Thanks.

> 
>> I'm really wondering how that could happen. The only thing that I
>> can think of is some strange timing issue, causing lost requests to
>> write the stats or maybe some of the stats updates. Hmmm, IIRC the
>> stats are sent over UDP - couldn't that be related?
> 
> yes, UDP packet drops can certainly happen.  This is considered a 
> feature (do not cause backends to block when the network socket to
> stat collector is swamped; it's better to lose some stat messages
> instead).

Is there anything we could add to the test to identify this? Something
that either shows "stats were sent" and "stats arrived" (maybe in the
log only), or that some UPD packets were dropped?

Tomas



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

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: Materialized views WIP patch
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Materialized views WIP patch