Re: buildfarm logging versus embedded nulls

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: buildfarm logging versus embedded nulls
Дата
Msg-id 20100312224625.GJ3663@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: buildfarm logging versus embedded nulls  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: buildfarm logging versus embedded nulls  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:

> > I also think the autovacuum worker minimum timestamp may be playing
> > games with the retry logic too.  Maybe a worker is requesting a new file
> > continuously because pgstat is not able to provide one before the
> > deadline is past, and thus overloading it.  I still think that 500ms is
> > too much for a worker, but backing off all the way to 10ms seems too
> > much.  Maybe it should just be, say, 100ms.
> 
> But we don't advance the deadline within the wait loop, so (in theory)
> a single requestor shouldn't be able to trigger more than one stats file
> update.

Hmm, yeah.

> I wonder though if an autovac worker could make many such
> requests over its lifespan ...

Well, yes, but it will request fresh stats only for the recheck logic
before each table, so there will be one intervening vacuum (or none,
actually, if the table was vacuumed by some other autovac worker.
Though given the default naptime of 1 min I find it unlikely that the
regression database will ever see more than one worker).

Since the warning comes from the launcher and not the worker, I wonder
if this is a red herring.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Dyamic updates of NEW with pl/pgsql
Следующее
От: Tom Lane
Дата:
Сообщение: Re: buildfarm logging versus embedded nulls