Re: "debug_invalidate_system_caches_always" is too long - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: "debug_invalidate_system_caches_always" is too long
Date
Msg-id CALj2ACVT4ga=RDYsBzLg3DXg2ENat2V-eh4yw8oH65Z1CNkJ6g@mail.gmail.com
Whole thread Raw
In response to Re: "debug_invalidate_system_caches_always" is too long  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "debug_invalidate_system_caches_always" is too long  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Tue, Jul 6, 2021 at 12:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Noah Misch <noah@leadboat.com> writes:
> > On Sun, Jul 04, 2021 at 04:27:13PM -0400, Tom Lane wrote:
> >> 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
> > that may ensnare folks looking for extra logging rather than a big slowdown.)
>
> I like "debug_flush_caches" --- it's short and accurate.

Do we always flush the cache entries into the disk? Sometimes we just
invalidate the cache entries in the registered invalidation callbacks,
right? Since we already use the term "clobber" in the user visible
config option --clobber-cache, isn't it consistent to use
debug_clobber_caches?

Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Parallel INSERT SELECT take 2
Next
From: Peter Smith
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions