Re: Protect syscache from bloating with negative cache entries

At Tue, 7 Mar 2017 19:23:14 -0800, David Steele <david(at)pgmasters(dot)net> wrote in <3b7b7f90-db46-8c37-c4f7-443330c3ae33(at)pgmasters(dot)net>
> On 3/3/17 4:54 PM, David Steele wrote:
>
> > On 2/1/17 1:25 AM, Kyotaro HORIGUCHI wrote:
> >> Hello, thank you for moving this to the next CF.
> >>
> >> At Wed, 1 Feb 2017 13:09:51 +0900, Michael Paquier
> >> <michael(dot)paquier(at)gmail(dot)com> wrote in
> >> <CAB7nPqRFhUv+GX=eH1bo7xYHS79-gRj1ecu2QoQtHvX9RS=JYA(at)mail(dot)gmail(dot)com>
> >>> On Tue, Jan 24, 2017 at 4:58 PM, Kyotaro HORIGUCHI
> >>> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> >>>> Six new syscaches in 665d1fa was conflicted and 3-way merge
> >>>> worked correctly. The new syscaches don't seem to be targets of
> >>>> this patch.
> >>> To be honest, I am not completely sure what to think about this patch.
> >>> Moved to next CF as there is a new version, and no new reviews to make
> >>> the discussion perhaps move on.
> >> I'm thinking the following is the status of this topic.
> >>
> >> - The patch stll is not getting conflicted.
> >>
> >> - This is not a hollistic measure for memory leak but surely
> >> saves some existing cases.
> >>
> >> - Shared catcache is another discussion (and won't really
> >> proposed in a short time due to the issue on locking.)
> >>
> >> - As I mentioned, a patch that caps the number of negative
> >> entries is avaiable (in first-created - first-delete manner)
> >> but it is having a loose end of how to determine the
> >> limitation.
> > While preventing bloat in the syscache is a worthwhile goal, it
> > appears
> > there are a number of loose ends here and a new patch has not been
> > provided.
> >
> > It's a pretty major change so I recommend moving this patch to the
> > 2017-07 CF.
>
> Not hearing any opinions pro or con, I'm moving this patch to the
> 2017-07 CF.

Ah. Yes, I agree on this. Thanks.

--
Kyotaro Horiguchi
NTT Open Source Software Center