From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | noah(at)leadboat(dot)com |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: "debug_invalidate_system_caches_always" is too long |
Date: | 2021-07-05 04:52:46 |
Message-ID: | 20210705.135246.391995433306544912.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Sun, 4 Jul 2021 14:12:34 -0700, Noah Misch <noah(at)leadboat(dot)com> wrote in
> > However, I think we should also give serious consideration to
> > "debug_clobber_cache" or "debug_clobber_cache_always" for continuity
> > with past practice (though it still feels like "always" is a good
> > word to lose now). "debug_clobber_caches" is another reasonable
> > variant.
>
> https://en.wikipedia.org/wiki/Clobbering refers to cases where storage had no
> changes to its accessibility but now contains different data. That doesn't
> match InvalidateSystemCaches() especially well, so I think dropping that word
> has been a good step. Some other shorter terms could be debug_flush_caches,
> debug_rebuild_caches, or debug_expire_caches. (debug_caches is tempting, but
(I murmur that I think "drop" is also usable here.)
> that may ensnare folks looking for extra logging rather than a big slowdown.)
I agree to this. (And one more +1 to removing "always".)
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Amul Sul | 2021-07-05 05:33:13 | Re: "debug_invalidate_system_caches_always" is too long |
Previous Message | Greg Nancarrow | 2021-07-05 03:14:02 | Re: row filtering for logical replication |