Re: "debug_invalidate_system_caches_always" is too long

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: "debug_invalidate_system_caches_always" is too long
Date: 2021-07-06 03:46:54
Message-ID: CALj2ACVT4ga=RDYsBzLg3DXg2ENat2V-eh4yw8oH65Z1CNkJ6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 6, 2021 at 12:43 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Noah Misch <noah(at)leadboat(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2021-07-06 04:28:06 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message houzj.fnst@fujitsu.com 2021-07-06 03:42:28 RE: Parallel INSERT SELECT take 2