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.
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 |