RE: Protect syscache from bloating with negative cache entries

Hi, thanks for recent rapid work.

>From: Kyotaro HORIGUCHI [mailto:horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp]
>At Tue, 5 Feb 2019 19:05:26 -0300, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
>wrote in <20190205220526(dot)GA1442(at)alvherre(dot)pgsql>
>> On 2019-Feb-05, Tomas Vondra wrote:
>>
>> > I don't think we need to remove the expired entries right away, if
>> > there are only very few of them. The cleanup requires walking the
>> > hash table, which means significant fixed cost. So if there are only
>> > few expired entries (say, less than 25% of the cache), we can just
>> > leave them around and clean them if we happen to stumble on them
>> > (although that may not be possible with dynahash, which has no
>> > concept of expiration) of before enlarging the hash table.
>>
>> I think seqscanning the hash table is going to be too slow;
>> Ideriha-san idea of having a dlist with the entries in LRU order
>> (where each entry is moved to head of list when it is touched) seemed
>> good: it allows you to evict older ones when the time comes, without
>> having to scan the rest of the entries. Having a dlist means two more
>> pointers on each cache entry AFAIR, so it's not a huge amount of memory.
>
>Ah, I had a separate list in my mind. Sounds reasonable to have pointers in cache entry.
>But I'm not sure how much additional
>dlist_* impact.

Thank you for picking up my comment, Alvaro.
That's what I was thinking about.

>The attached is the new version with the following properties:
>
>- Both prune-by-age and hard limiting feature.
> (Merged into single function, single scan)
> Debug tracking feature in CatCacheCleanupOldEntries is removed
> since it no longer runs a full scan.
It seems to me that adding hard limit strategy choice besides prune-by-age one is good
to help variety of (contradictory) cases which have been discussed in this thread. I need hard limit as well.

The hard limit is currently represented as number of cache entry
controlled by both cache_entry_limit and cache_entry_limit_prune_ratio.
Why don't we change it to the amount of memory (bytes)?
Amount of memory is more direct parameter for customer who wants to
set the hard limit and easier to tune compared to number of cache entry.

>- Using LRU to get rid of full scan.
>
>I added new API dlist_move_to_tail which was needed to construct LRU.

I just thought there is dlist_move_head() so if new entries are
head side and old ones are tail side. But that's not objection to adding
new API because depending on the situation head for new entry could be readable code
and vice versa.

Regards,
Takeshi Ideriha