| From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
|---|---|
| To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, 'Tomas Vondra' <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | "alvherre(at)2ndquadrant(dot)com" <alvherre(at)2ndquadrant(dot)com>, "bruce(at)momjian(dot)us" <bruce(at)momjian(dot)us>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "michael(dot)paquier(at)gmail(dot)com" <michael(dot)paquier(at)gmail(dot)com>, "david(at)pgmasters(dot)net" <david(at)pgmasters(dot)net>, "craig(at)2ndquadrant(dot)com" <craig(at)2ndquadrant(dot)com> |
| Subject: | RE: Protect syscache from bloating with negative cache entries |
| Date: | 2019-02-13 02:15:42 |
| Message-ID: | 0A3221C70F24FB45833433255569204D1FB97CF1@G01JPEXMBYT05 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Tomas Vondra [mailto:tomas(dot)vondra(at)2ndquadrant(dot)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 item would 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 system catalogs. That may result in OOM, and this patch can rescue it.
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shawn Debnath | 2019-02-13 02:58:43 | Re: Refactoring the checkpointer's fsync request queue |
| Previous Message | Tsunakawa, Takayuki | 2019-02-13 01:48:40 | RE: Reaping Temp tables to avoid XID wraparound |