Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)
Date
Msg-id 20140517214550.GE4484@awork2.anarazel.de
Whole thread Raw
In response to Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)  (Tomas Vondra <tv@fuzzy.cz>)
Responses Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY)
List 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 by date:

Previous
From: Christoph Berg
Date:
Subject: Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Next
From: Andres Freund
Date:
Subject: Re: %d in log_line_prefix doesn't work for bg/autovacuum workers