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

From Tom Lane
Subject "debug_invalidate_system_caches_always" is too long
Date
Msg-id 1374320.1625430433@sss.pgh.pa.us
Whole thread Raw
Responses Re: "debug_invalidate_system_caches_always" is too long  (Noah Misch <noah@leadboat.com>)
Re: "debug_invalidate_system_caches_always" is too long  (Justin Pryzby <pryzby@telsasoft.com>)
Re: "debug_invalidate_system_caches_always" is too long  (Amul Sul <sulamul@gmail.com>)
Re: "debug_invalidate_system_caches_always" is too long  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Re: "debug_invalidate_system_caches_always" is too long  (Andrew Dunstan <andrew@dunslane.net>)
Re: "debug_invalidate_system_caches_always" is too long  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
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?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Excessive cost of OpClassCache flushes in CLOBBER_CACHE_ALWAYS mode
Next
From: Fabien COELHO
Date:
Subject: Re: rand48 replacement