Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)
Дата
Msg-id 20140517214550.GE4484@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)  (Tomas Vondra <tv@fuzzy.cz>)
Ответы Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)
Список pgsql-hackers
On 2014-05-17 22:55:14 +0200, Tomas Vondra wrote:
> And another memory context stats for a session executing CREATE INDEX,
> while having allocated  The interesting thing is there are ~11k lines
> that look exactly like this:
> 
> pg_namespace_oid_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used

Heh. That certainly doesn't look right. I bet it's the contexts from
RelationInitIndexAccessInfo().

Looks like there generally are recursion 'troubles' with system
indexes. RelationClearRelation() will mark them as invalid causing any
further lookup to do RelationBuildDesc() calls. Which will again rebuild
the same relation if it's used somewhere inside RelationBuildDesc() or
RelationInitIndexAccessInfo(). From a quick look it looks like it should
resolve itself after some time. Even freeing the superflous memory
contexts. But I am not sure if there scenarios where that won't
happen...


Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Christoph Berg
Дата:
Сообщение: Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Следующее
От: Andres Freund
Дата:
Сообщение: Re: %d in log_line_prefix doesn't work for bg/autovacuum workers