From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: buildfarm: strange OOM failures on markhor (running CLOBBER_CACHE_RECURSIVELY) |
Date: | 2014-05-17 21:45:50 |
Message-ID: | 20140517214550.GE4484@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-05-17 21:50:25 | Re: %d in log_line_prefix doesn't work for bg/autovacuum workers |
Previous Message | Christoph Berg | 2014-05-17 21:35:43 | Re: %d in log_line_prefix doesn't work for bg/autovacuum workers |