Re: Protect syscache from bloating with negative cache entries

Thank you for pointing out the stupidity. (Tom did earlier, though.)

At Mon, 21 Jan 2019 07:12:41 +0000, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote in <0A3221C70F24FB45833433255569204D1FB6C78A(at)G01JPEXMBYT05>
> From: Kyotaro HORIGUCHI [mailto:horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp]
> > 0003: Remote GUC setting
> >
> > It is independent from the above two, and heavily arguable.
> >
> > pg_set_backend_config(pid, name, value) changes the GUC <name> on the
> > backend with <pid> to <value>.
> >
>
> Not having looked at the code yet, why did you think this is necessary? Can't we always collect the cache stats? Is it heavy due to some locking in the shared memory, or sending the stats to the stats collector?

Yeah, I had a fun making it but I don't think it can be said very
good. I must admit that it is a kind of too-much or something
stupid.

Anyway it needs to scan the whole hash to collect numbers and I
don't see how to elimite the complexity without a penalty on
regular code paths for now. I don't want do that always for the
reason.

An option is an additional PGPROC member and interface functions.

struct PGPROC
{
...
int syscahe_usage_track_interval; /* track interval, 0 to disable */

=# select syscahce_usage_track_add(<pid>, <intvl>[, <repetition>]);
=# select syscahce_usage_track_remove(2134);

Or, just provide an one-shot triggering function.

=# select syscahce_take_usage_track(<pid>);

This can use both a similar PGPROC variable or SendProcSignal()
but the former doesn't fire while idle time unless using timer.

Any thoughts?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center