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 CALj2ACWKz91tdfjVyfdxEayApH0k0D2wsVqUg8Rz4i5MB44Vqw@mail.gmail.com
Whole thread Raw
In response to "debug_invalidate_system_caches_always" is too long  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jul 5, 2021 at 1:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> As I've been poking around in this area, I find myself growing
> increasingly annoyed at the new GUC name
> "debug_invalidate_system_caches_always".  It is too d*mn long.
> It's a serious pain to type in any context where you don't have
> autocomplete to help you.  I've kept referring to this type of
> testing as CLOBBER_CACHE_ALWAYS testing, even though that name is
> now obsolete, just because it's so much shorter.  I think we need
> to reconsider this name while we still can.
>
> I do agree with the "debug_" prefix given that it's now visible to
> users.  However, it doesn't seem that hard to save some space in
> the rest of the name.  The word "system" is adding nothing of value,
> and the word "always" seems rather confusing --- if it does
> something "always", why is there more than one level?  So a simple
> proposal is to rename it to "debug_invalidate_caches".
>
> 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.
>
> Thoughts?

+1. IMO, debug_clobber_caches is better because it is simple.  And
also, since the invalidation happens on multiple system caches,
debug_clobber_caches is preferable than debug_clobber_cache.

Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Can a child process detect postmaster death when in pg_usleep?
Next
From: Emre Hasegeli
Date:
Subject: Re: Yet another fast GiST build