| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, robertmhaas(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, michael(dot)paquier(at)gmail(dot)com, david(at)pgmasters(dot)net, Jim(dot)Nasby(at)bluetreble(dot)com, craig(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Protect syscache from bloating with negative cache entries |
| Date: | 2018-03-07 17:37:19 |
| Message-ID: | 20180307173719.jxj7ybekicjk2j4k@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2018-03-07 08:01:38 -0300, Alvaro Herrera wrote:
> I wonder if this is just because we refuse to acknowledge the notion of
> a connection pooler. If we did, and the pooler told us "here, this
> session is being given back to us by the application, we'll keep it
> around until the next app comes along", could we clean the oldest
> inactive cache entries at that point? Currently they use DISCARD for
> that. Though this does nothing to fix hypothetical cache bloat for
> pg_dump in bug #14936.
I'm not seeing how this solves anything? You don't want to throw all
caches away, therefore you need a target size. Then there's also the
case of the cache being too large in a single "session".
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-03-07 17:48:48 | Re: Protect syscache from bloating with negative cache entries |
| Previous Message | Andres Freund | 2018-03-07 17:34:44 | Re: GSoC 2017: weekly progress reports (week 6) |