RE: Protect syscache from bloating with negative cache entries

From: Tomas Vondra [mailto:tomas.vondra@2ndquadrant.com]
> > I didin't consider planning that happen within a function. If
> > 5min is the default for catalog_cache_prune_min_age, 10% of it
> > (30s) seems enough and gettieofday() with such intervals wouldn't
> > affect forground jobs. I'd choose catalog_c_p_m_age/10 rather
> > than fixed value 30s and 1s as the minimal.
> >
> 
> Actually, I see CatCacheCleanupOldEntries contains this comment:
> 
> /*
>  * Calculate the duration from the time of the last access to the
>  * "current" time. Since catcacheclock is not advanced within a
>  * transaction, the entries that are accessed within the current
>  * transaction won't be pruned.
>  */
> 
> which I think is pretty much what I've been saying ... But the question
> is whether we need to do something about it.

Hmm, I'm surprised at v14 patch about this.  I remember that previous patches renewed the cache clock on every
statement,and it is correct.  If the cache clock is only updated at the beginning of a transaction, the following TODO
itemwould not be solved:
 

https://wiki.postgresql.org/wiki/Todo

" Reduce memory use when analyzing many tables in a single command by making catcache and syscache flushable or
bounded."

Also, Tom mentioned pg_dump in this thread (protect syscache...).  pg_dump runs in a single transaction, touching all
systemcatalogs.  That may result in OOM, and this patch can rescue it.
 


Regards
Takayuki Tsunakawa