On Tue, Jun 18, 2013 at 09:07:59PM +0300, Heikki Linnakangas wrote:
> >Hmm. I could repeat this, and it seems that the catcache for
> >pg_statistic accumulates negative cache entries. Those slowly take up
> >the memory.
>
> Digging a bit deeper, this is a rather common problem with negative
> catcache entries. In general, nothing stops you from polluting the
> cache with as many negative cache entries as you like. Just do
> "select * from table_that_doesnt_exist" for as many non-existent
> table names as you want, for example. Those entries are useful at
> least in theory; they speed up throwing the error the next time you
> try to query the same non-existent table.
>
> But there is a crucial difference in this case; the system created a
> negative cache entry for the pg_statistic row of the table, but once
> the relation is dropped, the cache entry keyed on the relation's
> OID, is totally useless. It should be removed.
>
> We have this problem with a few other catcaches too, which have what
> is effectively a foreign key relationship with another catalog. For
> example, the RELNAMENSP catcache is keyed on pg_class.relname,
> pg_class.relnamespace, yet any negative entries are not cleaned up
> when the schema is dropped. If you execute this repeatedly in a
> session:
>
> CREATE SCHEMA foo;
> SELECT * from foo.invalid; -- throws an error
> DROP SCHEMA foo;
>
> it will leak similarly to the original test case, but this time the
> leak is into the RELNAMENSP catcache.
>
> To fix that, I think we'll need to teach the catalog cache about the
> relationships between the caches.
Is this a TODO?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +