Thread: "debug_invalidate_system_caches_always" is too long

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

On Sun, Jul 04, 2021 at 04:27:13PM -0400, Tom Lane 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".

I agree with all that.  The word "always" has been misinformation, given the
multiple levels available.

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

On Sun, Jul 04, 2021 at 04:27:13PM -0400, Tom Lane wrote:
> 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".

+1 to remove "always"

-- 
Justin

At Sun, 4 Jul 2021 14:12:34 -0700, Noah Misch <noah@leadboat.com> wrote in 
> > 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

(I murmur that I think "drop" is also usable here.)

> that may ensnare folks looking for extra logging rather than a big slowdown.)

I agree to this.  (And one more +1 to removing "always".)

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

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 for the "debug_clobber_caches" variant, easy to remember.

Regards,
Amul

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.

On 7/4/21 4:27 PM, Tom Lane 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.
>


+1 for debug_invalidate_caches - it seems to have the most content and
least noise. Second choice would be debug_clobber_caches.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

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.

            regards, tom lane

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.

On 7/5/21 11:46 PM, Bharath Rupireddy wrote:
> 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?
>

I think 'flush' here means simply 'discard'. Maybe that would be a
better word to use.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Andrew Dunstan <andrew@dunslane.net> writes:
> On 7/5/21 11:46 PM, Bharath Rupireddy wrote:
>> On Tue, Jul 6, 2021 at 12:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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?

> I think 'flush' here means simply 'discard'. Maybe that would be a
> better word to use.

"Discard" could be misinterpreted too, no doubt.  None of these words
have one single exact meaning, so I have only limited patience for
this sort of argumentation.

(As for initdb's "--clobber-cache", I'm assuming we'd rename that to
match whatever we come up with here.  It is what it is now only because
I was unwilling to call it "--use-debug-invalidate-system-caches-always".)

            regards, tom lane

On 04.07.21 22:27, Tom Lane wrote:
> 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".

I think we can definitely drop the "always".  Not so much the "system", 
since there are other caches, but it would be ok if we want it shorter.

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

The clobbering doesn't actually happen unless you turn on 
CLOBBER_FREED_MEMORY, so it would be good to keep that separate.

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> The clobbering doesn't actually happen unless you turn on 
> CLOBBER_FREED_MEMORY, so it would be good to keep that separate.

Fair point.  What do you think of the alternative proposals
"debug_flush_caches", "debug_discard_caches", etc?

            regards, tom lane

On Wed, Jul 7, 2021 at 11:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> > The clobbering doesn't actually happen unless you turn on
> > CLOBBER_FREED_MEMORY, so it would be good to keep that separate.
>
> Fair point.  What do you think of the alternative proposals
> "debug_flush_caches", "debug_discard_caches", etc?

I like debug_discard_caches best. I have no preference between
debug_flush_caches and debug_clobber_caches; neither seems horrid. I
agree that what we're doing here is not precisely a "clobber" in the
usual sense, but the people who are apt to be using it will probably
be aware of that. Yet, it's good to try to clear things up for future
hackers, and IMHO debug_discard_caches is the clearest, so that's why
I like it a little better than the other choices.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jul 7, 2021 at 11:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Fair point.  What do you think of the alternative proposals
>> "debug_flush_caches", "debug_discard_caches", etc?

> I like debug_discard_caches best.

I can live with that.  Anyone strongly against it?

            regards, tom lane

On 2021-Jul-08, Tom Lane wrote:

> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Jul 7, 2021 at 11:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Fair point.  What do you think of the alternative proposals
> >> "debug_flush_caches", "debug_discard_caches", etc?
> 
> > I like debug_discard_caches best.
> 
> I can live with that.  Anyone strongly against it?

Seems fine to me.

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/
"Just treat us the way you want to be treated + some extra allowance
 for ignorance."                                    (Michael Brusser)

On Thu, Jul 08, 2021 at 04:34:55PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Jul 7, 2021 at 11:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Fair point.  What do you think of the alternative proposals
> >> "debug_flush_caches", "debug_discard_caches", etc?
> 
> > I like debug_discard_caches best.
> 
> I can live with that.  Anyone strongly against it?

I like it.

Noah Misch <noah@leadboat.com> writes:
> On Thu, Jul 08, 2021 at 04:34:55PM -0400, Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> I like debug_discard_caches best.

>> I can live with that.  Anyone strongly against it?

> I like it.

Hearing no votes against, here's a proposed patch for that.

(This is for HEAD; I expect v14 will need additional adjustments
in release-14.sgml)

            regards, tom lane

diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres_fdw/expected/postgres_fdw.out
index b8561d6a3c..e5bbf3b0af 100644
--- a/contrib/postgres_fdw/expected/postgres_fdw.out
+++ b/contrib/postgres_fdw/expected/postgres_fdw.out
@@ -9340,11 +9340,11 @@ WARNING:  there is no transaction in progress
 -- Change application_name of remote connection to special one
 -- so that we can easily terminate the connection later.
 ALTER SERVER loopback OPTIONS (application_name 'fdw_retry_check');
--- If debug_invalidate_system_caches_always is active, it results in
+-- If debug_discard_caches is active, it results in
 -- dropping remote connections after every transaction, making it
 -- impossible to test termination meaningfully.  So turn that off
 -- for this test.
-SET debug_invalidate_system_caches_always = 0;
+SET debug_discard_caches = 0;
 -- Make sure we have a remote connection.
 SELECT 1 FROM ft1 LIMIT 1;
  ?column?
@@ -9386,7 +9386,7 @@ SELECT 1 FROM ft1 LIMIT 1;    -- should fail
 ERROR:  08006
 \set VERBOSITY default
 COMMIT;
-RESET debug_invalidate_system_caches_always;
+RESET debug_discard_caches;
 -- =============================================================================
 -- test connection invalidation cases and postgres_fdw_get_connections function
 -- =============================================================================
diff --git a/contrib/postgres_fdw/sql/postgres_fdw.sql b/contrib/postgres_fdw/sql/postgres_fdw.sql
index c283e74715..fe503ed6c3 100644
--- a/contrib/postgres_fdw/sql/postgres_fdw.sql
+++ b/contrib/postgres_fdw/sql/postgres_fdw.sql
@@ -2831,11 +2831,11 @@ ROLLBACK;
 -- so that we can easily terminate the connection later.
 ALTER SERVER loopback OPTIONS (application_name 'fdw_retry_check');

--- If debug_invalidate_system_caches_always is active, it results in
+-- If debug_discard_caches is active, it results in
 -- dropping remote connections after every transaction, making it
 -- impossible to test termination meaningfully.  So turn that off
 -- for this test.
-SET debug_invalidate_system_caches_always = 0;
+SET debug_discard_caches = 0;

 -- Make sure we have a remote connection.
 SELECT 1 FROM ft1 LIMIT 1;
@@ -2861,7 +2861,7 @@ SELECT 1 FROM ft1 LIMIT 1;    -- should fail
 \set VERBOSITY default
 COMMIT;

-RESET debug_invalidate_system_caches_always;
+RESET debug_discard_caches;

 -- =============================================================================
 -- test connection invalidation cases and postgres_fdw_get_connections function
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 381d8636ab..d1b889b80f 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -10341,10 +10341,10 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
       </listitem>
      </varlistentry>

-     <varlistentry id="guc-debug-invalidate-system-caches-always" xreflabel="debug_invalidate_system_caches_always">
-      <term><varname>debug_invalidate_system_caches_always</varname> (<type>integer</type>)
+     <varlistentry id="guc-debug-discard-caches" xreflabel="debug_discard_caches">
+      <term><varname>debug_discard_caches</varname> (<type>integer</type>)
       <indexterm>
-       <primary><varname>debug_invalidate_system_caches_always</varname> configuration parameter</primary>
+       <primary><varname>debug_discard_caches</varname> configuration parameter</primary>
       </indexterm>
       </term>
       <listitem>
@@ -10369,7 +10369,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'

        <para>
         This parameter is supported when
-        <symbol>CLOBBER_CACHE_ENABLED</symbol> was defined at compile time
+        <symbol>DISCARD_CACHES_ENABLED</symbol> was defined at compile time
         (which happens automatically when using the
         <application>configure</application> option
         <option>--enable-cassert</option>).  In production builds, its value
diff --git a/doc/src/sgml/ref/initdb.sgml b/doc/src/sgml/ref/initdb.sgml
index 3077530c7b..e62742850a 100644
--- a/doc/src/sgml/ref/initdb.sgml
+++ b/doc/src/sgml/ref/initdb.sgml
@@ -388,17 +388,6 @@ PostgreSQL documentation
     Other, less commonly used, options are also available:

     <variablelist>
-     <varlistentry>
-      <term><option>--clobber-cache</option></term>
-      <listitem>
-       <para>
-        Run the bootstrap backend with the
-        <literal>debug_invalidate_system_caches_always=1</literal> option.
-        This takes a very long time and is only of use for deep debugging.
-       </para>
-      </listitem>
-     </varlistentry>
-
      <varlistentry>
       <term><option>-d</option></term>
       <term><option>--debug</option></term>
@@ -413,6 +402,17 @@ PostgreSQL documentation
       </listitem>
      </varlistentry>

+     <varlistentry>
+      <term><option>--discard-caches</option></term>
+      <listitem>
+       <para>
+        Run the bootstrap backend with the
+        <literal>debug_discard_caches=1</literal> option.
+        This takes a very long time and is only of use for deep debugging.
+       </para>
+      </listitem>
+     </varlistentry>
+
      <varlistentry>
       <term><option>-L <replaceable class="parameter">directory</replaceable></option></term>
       <listitem>
diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
index c35e036028..acc7a50c2f 100644
--- a/doc/src/sgml/regress.sgml
+++ b/doc/src/sgml/regress.sgml
@@ -373,7 +373,7 @@ make check EXTRA_REGRESS_OPTS="--temp-config=test_postgresql.conf"
    <para>
     This can be useful to enable additional logging, adjust resource limits,
     or enable extra run-time checks such as <xref
-    linkend="guc-debug-invalidate-system-caches-always"/>.
+    linkend="guc-debug-discard-caches"/>.
    </para>
   </sect2>

diff --git a/src/backend/utils/adt/lockfuncs.c b/src/backend/utils/adt/lockfuncs.c
index 085fec3ea2..5dc0a5882c 100644
--- a/src/backend/utils/adt/lockfuncs.c
+++ b/src/backend/utils/adt/lockfuncs.c
@@ -636,10 +636,10 @@ pg_isolation_test_session_is_blocked(PG_FUNCTION_ARGS)
      * Check if any of these are in the list of interesting PIDs, that being
      * the sessions that the isolation tester is running.  We don't use
      * "arrayoverlaps" here, because it would lead to cache lookups and one of
-     * our goals is to run quickly with debug_invalidate_system_caches_always
-     * > 0.  We expect blocking_pids to be usually empty and otherwise a very
-     * small number in isolation tester cases, so make that the outer loop of
-     * a naive search for a match.
+     * our goals is to run quickly with debug_discard_caches > 0.  We expect
+     * blocking_pids to be usually empty and otherwise a very small number in
+     * isolation tester cases, so make that the outer loop of a naive search
+     * for a match.
      */
     for (i = 0; i < num_blocking_pids; i++)
         for (j = 0; j < num_interesting_pids; j++)
diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
index d22cc5a93b..9c79775725 100644
--- a/src/backend/utils/cache/inval.c
+++ b/src/backend/utils/cache/inval.c
@@ -182,7 +182,7 @@ static int    numSharedInvalidMessagesArray;
 static int    maxSharedInvalidMessagesArray;

 /* GUC storage */
-int            debug_invalidate_system_caches_always = 0;
+int            debug_discard_caches = 0;

 /*
  * Dynamically-registered callback functions.  Current implementation
@@ -690,7 +690,7 @@ AcceptInvalidationMessages(void)
     ReceiveSharedInvalidMessages(LocalExecuteInvalidationMessage,
                                  InvalidateSystemCaches);

-    /*
+    /*----------
      * Test code to force cache flushes anytime a flush could happen.
      *
      * This helps detect intermittent faults caused by code that reads a cache
@@ -698,28 +698,28 @@ AcceptInvalidationMessages(void)
      * rarely actually does so.  This can spot issues that would otherwise
      * only arise with badly timed concurrent DDL, for example.
      *
-     * The default debug_invalidate_system_caches_always = 0 does no forced
-     * cache flushes.
+     * The default debug_discard_caches = 0 does no forced cache flushes.
      *
      * If used with CLOBBER_FREED_MEMORY,
-     * debug_invalidate_system_caches_always = 1 (CLOBBER_CACHE_ALWAYS)
+     * debug_discard_caches = 1 (formerly known as CLOBBER_CACHE_ALWAYS)
      * provides a fairly thorough test that the system contains no cache-flush
      * hazards.  However, it also makes the system unbelievably slow --- the
      * regression tests take about 100 times longer than normal.
      *
      * If you're a glutton for punishment, try
-     * debug_invalidate_system_caches_always = 3 (CLOBBER_CACHE_RECURSIVELY).
+     * debug_discard_caches = 3 (formerly known as CLOBBER_CACHE_RECURSIVELY).
      * This slows things by at least a factor of 10000, so I wouldn't suggest
      * trying to run the entire regression tests that way.  It's useful to try
      * a few simple tests, to make sure that cache reload isn't subject to
      * internal cache-flush hazards, but after you've done a few thousand
      * recursive reloads it's unlikely you'll learn more.
+     *----------
      */
-#ifdef CLOBBER_CACHE_ENABLED
+#ifdef DISCARD_CACHES_ENABLED
     {
         static int    recursion_depth = 0;

-        if (recursion_depth < debug_invalidate_system_caches_always)
+        if (recursion_depth < debug_discard_caches)
         {
             recursion_depth++;
             InvalidateSystemCaches();
diff --git a/src/backend/utils/cache/plancache.c b/src/backend/utils/cache/plancache.c
index 07b0145132..6767eae8f2 100644
--- a/src/backend/utils/cache/plancache.c
+++ b/src/backend/utils/cache/plancache.c
@@ -897,9 +897,8 @@ BuildCachedPlan(CachedPlanSource *plansource, List *qlist,
      * rejected a generic plan, it's possible to reach here with is_valid
      * false due to an invalidation while making the generic plan.  In theory
      * the invalidation must be a false positive, perhaps a consequence of an
-     * sinval reset event or the debug_invalidate_system_caches_always code.
-     * But for safety, let's treat it as real and redo the
-     * RevalidateCachedQuery call.
+     * sinval reset event or the debug_discard_caches code.  But for safety,
+     * let's treat it as real and redo the RevalidateCachedQuery call.
      */
     if (!plansource->is_valid)
         qlist = RevalidateCachedQuery(plansource, queryEnv);
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c
index 5dac9f0696..13d9994af3 100644
--- a/src/backend/utils/cache/relcache.c
+++ b/src/backend/utils/cache/relcache.c
@@ -97,7 +97,7 @@
 #define MAYBE_RECOVER_RELATION_BUILD_MEMORY 1
 #else
 #define RECOVER_RELATION_BUILD_MEMORY 0
-#ifdef CLOBBER_CACHE_ENABLED
+#ifdef DISCARD_CACHES_ENABLED
 #define MAYBE_RECOVER_RELATION_BUILD_MEMORY 1
 #endif
 #endif
@@ -1011,10 +1011,10 @@ RelationBuildDesc(Oid targetRelId, bool insertIt)
      * data, reasoning that the caller's context is at worst of transaction
      * scope, and relcache loads shouldn't happen so often that it's essential
      * to recover transient data before end of statement/transaction.  However
-     * that's definitely not true in clobber-cache test builds, and perhaps
-     * it's not true in other cases.
+     * that's definitely not true when debug_discard_caches is active, and
+     * perhaps it's not true in other cases.
      *
-     * When cache clobbering is enabled or when forced to by
+     * When debug_discard_caches is active or when forced to by
      * RECOVER_RELATION_BUILD_MEMORY=1, arrange to allocate the junk in a
      * temporary context that we'll free before returning.  Make it a child of
      * caller's context so that it will get cleaned up appropriately if we
@@ -1024,7 +1024,7 @@ RelationBuildDesc(Oid targetRelId, bool insertIt)
     MemoryContext tmpcxt = NULL;
     MemoryContext oldcxt = NULL;

-    if (RECOVER_RELATION_BUILD_MEMORY || debug_invalidate_system_caches_always > 0)
+    if (RECOVER_RELATION_BUILD_MEMORY || debug_discard_caches > 0)
     {
         tmpcxt = AllocSetContextCreate(CurrentMemoryContext,
                                        "RelationBuildDesc workspace",
@@ -1627,11 +1627,10 @@ LookupOpclassInfo(Oid operatorClassOid,
      * otherwise.  However it can be helpful for detecting bugs in the cache
      * loading logic itself, such as reliance on a non-nailed index.  Given
      * the limited use-case and the fact that this adds a great deal of
-     * expense, we enable it only for high values of
-     * debug_invalidate_system_caches_always.
+     * expense, we enable it only for high values of debug_discard_caches.
      */
-#ifdef CLOBBER_CACHE_ENABLED
-    if (debug_invalidate_system_caches_always > 2)
+#ifdef DISCARD_CACHES_ENABLED
+    if (debug_discard_caches > 2)
         opcentry->valid = false;
 #endif

diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 480e8cd199..45a053ca40 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -3513,13 +3513,13 @@ static struct config_int ConfigureNamesInt[] =
     },

     {
-        {"debug_invalidate_system_caches_always", PGC_SUSET, DEVELOPER_OPTIONS,
-            gettext_noop("Aggressively invalidate system caches for debugging purposes."),
+        {"debug_discard_caches", PGC_SUSET, DEVELOPER_OPTIONS,
+            gettext_noop("Aggressively flush system caches for debugging purposes."),
             NULL,
             GUC_NOT_IN_SAMPLE
         },
-        &debug_invalidate_system_caches_always,
-#ifdef CLOBBER_CACHE_ENABLED
+        &debug_discard_caches,
+#ifdef DISCARD_CACHES_ENABLED
         /* Set default based on older compile-time-only cache clobber macros */
 #if defined(CLOBBER_CACHE_RECURSIVELY)
         3,
@@ -3529,9 +3529,9 @@ static struct config_int ConfigureNamesInt[] =
         0,
 #endif
         0, 5,
-#else                            /* not CLOBBER_CACHE_ENABLED */
+#else                            /* not DISCARD_CACHES_ENABLED */
         0, 0, 0,
-#endif                            /* not CLOBBER_CACHE_ENABLED */
+#endif                            /* not DISCARD_CACHES_ENABLED */
         NULL, NULL, NULL
     },

diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index 0945d70061..77e621a767 100644
--- a/src/bin/initdb/initdb.c
+++ b/src/bin/initdb/initdb.c
@@ -2266,8 +2266,8 @@ usage(const char *progname)
     printf(_("  -X, --waldir=WALDIR       location for the write-ahead log directory\n"));
     printf(_("      --wal-segsize=SIZE    size of WAL segments, in megabytes\n"));
     printf(_("\nLess commonly used options:\n"));
-    printf(_("      --clobber-cache       use cache-clobbering debug option\n"));
     printf(_("  -d, --debug               generate lots of debugging output\n"));
+    printf(_("      --discard-caches      set debug_discard_caches=1\n"));
     printf(_("  -L DIRECTORY              where to find the input files\n"));
     printf(_("  -n, --no-clean            do not clean up after errors\n"));
     printf(_("  -N, --no-sync             do not wait for changes to be written safely to disk\n"));
@@ -2947,7 +2947,7 @@ main(int argc, char *argv[])
         {"wal-segsize", required_argument, NULL, 12},
         {"data-checksums", no_argument, NULL, 'k'},
         {"allow-group-access", no_argument, NULL, 'g'},
-        {"clobber-cache", no_argument, NULL, 14},
+        {"discard-caches", no_argument, NULL, 14},
         {NULL, 0, NULL, 0}
     };

@@ -3092,7 +3092,7 @@ main(int argc, char *argv[])
             case 14:
                 extra_options = psprintf("%s %s",
                                          extra_options,
-                                         "-c debug_invalidate_system_caches_always=1");
+                                         "-c debug_discard_caches=1");
                 break;
             default:
                 /* getopt_long already emitted a complaint */
diff --git a/src/include/pg_config_manual.h b/src/include/pg_config_manual.h
index 27da86e5e0..614035e215 100644
--- a/src/include/pg_config_manual.h
+++ b/src/include/pg_config_manual.h
@@ -322,36 +322,36 @@
 /* #define RANDOMIZE_ALLOCATED_MEMORY */

 /*
- * For cache invalidation debugging, define CLOBBER_CACHE_ENABLED to enable
- * use of the debug_invalidate_system_caches_always GUC to aggressively flush
- * syscache/relcache entries whenever it's possible to deliver invalidations.
- * See AcceptInvalidationMessages() in src/backend/utils/cache/inval.c for
+ * For cache-invalidation debugging, define DISCARD_CACHES_ENABLED to enable
+ * use of the debug_discard_caches GUC to aggressively flush syscache/relcache
+ * entries whenever it's possible to deliver invalidations.  See
+ * AcceptInvalidationMessages() in src/backend/utils/cache/inval.c for
  * details.
  *
  * USE_ASSERT_CHECKING builds default to enabling this.  It's possible to use
- * CLOBBER_CACHE_ENABLED without a cassert build and the implied
- * CLOBBER_FREED_MEMORY and MEMORY_CONTEXT_CHECKING options but it's unlikely
+ * DISCARD_CACHES_ENABLED without a cassert build and the implied
+ * CLOBBER_FREED_MEMORY and MEMORY_CONTEXT_CHECKING options, but it's unlikely
  * to be as effective at identifying problems.
  */
-/* #define CLOBBER_CACHE_ENABLED */
+/* #define DISCARD_CACHES_ENABLED */

-#if defined(USE_ASSERT_CHECKING) && !defined(CLOBBER_CACHE_ENABLED)
-#define CLOBBER_CACHE_ENABLED
+#if defined(USE_ASSERT_CHECKING) && !defined(DISCARD_CACHES_ENABLED)
+#define DISCARD_CACHES_ENABLED
 #endif

 /*
- * Backwards compatibility for the older compile-time-only cache clobber
+ * Backwards compatibility for the older compile-time-only clobber-cache
  * macros.
  */
-#if !defined(CLOBBER_CACHE_ENABLED) && (defined(CLOBBER_CACHE_ALWAYS) || defined(CLOBBER_CACHE_RECURSIVELY))
-#define CLOBBER_CACHE_ENABLED
+#if !defined(DISCARD_CACHES_ENABLED) && (defined(CLOBBER_CACHE_ALWAYS) || defined(CLOBBER_CACHE_RECURSIVELY))
+#define DISCARD_CACHES_ENABLED
 #endif

 /*
  * Recover memory used for relcache entries when invalidated.  See
  * RelationBuildDescr() in src/backend/utils/cache/relcache.c.
  *
- * This is active automatically for clobber cache builds when clobbering is
+ * This is active automatically for clobber-cache builds when clobbering is
  * active, but can be overridden here by explicitly defining
  * RECOVER_RELATION_BUILD_MEMORY.  Define to 1 to always free relation cache
  * memory even when clobber is off, or to 0 to never free relation cache
diff --git a/src/include/utils/inval.h b/src/include/utils/inval.h
index a7e04722d0..770672890b 100644
--- a/src/include/utils/inval.h
+++ b/src/include/utils/inval.h
@@ -18,7 +18,7 @@
 #include "storage/relfilenode.h"
 #include "utils/relcache.h"

-extern PGDLLIMPORT int debug_invalidate_system_caches_always;
+extern PGDLLIMPORT int debug_discard_caches;

 typedef void (*SyscacheCallbackFunction) (Datum arg, int cacheid, uint32 hashvalue);
 typedef void (*RelcacheCallbackFunction) (Datum arg, Oid relid);
diff --git a/src/pl/plpgsql/src/expected/plpgsql_cache.out b/src/pl/plpgsql/src/expected/plpgsql_cache.out
index cc0c57b879..9df188ce56 100644
--- a/src/pl/plpgsql/src/expected/plpgsql_cache.out
+++ b/src/pl/plpgsql/src/expected/plpgsql_cache.out
@@ -3,10 +3,10 @@
 --
 -- These tests logically belong in plpgsql_record.sql, and perhaps someday
 -- can be merged back into it.  For now, however, their results are different
--- depending on debug_invalidate_system_caches_always, so we must have two
--- expected-output files to cover both cases.  To minimize the maintenance
--- effort resulting from that, this file should contain only tests that
--- do have different results under debug_invalidate_system_caches_always.
+-- depending on debug_discard_caches, so we must have two expected-output
+-- files to cover both cases.  To minimize the maintenance effort resulting
+-- from that, this file should contain only tests that do have different
+-- results under debug_discard_caches.
 --
 -- check behavior with changes of a named rowtype
 create table c_mutable(f1 int, f2 text);
@@ -21,7 +21,7 @@ select c_sillyaddone(42);
 alter table c_mutable drop column f1;
 alter table c_mutable add column f1 float8;
 -- currently, this fails due to cached plan for "r.f1 + 1" expression
--- (but if debug_invalidate_system_caches_always is on, it will succeed)
+-- (but if debug_discard_caches is on, it will succeed)
 select c_sillyaddone(42);
 ERROR:  type of parameter 4 (double precision) does not match that when preparing the plan (integer)
 CONTEXT:  PL/pgSQL function c_sillyaddone(integer) line 1 at RETURN
@@ -52,7 +52,7 @@ select show_result_type('select 1 as a');
 (1 row)

 -- currently this fails due to cached plan for pg_typeof expression
--- (but if debug_invalidate_system_caches_always is on, it will succeed)
+-- (but if debug_discard_caches is on, it will succeed)
 select show_result_type('select 2.0 as a');
 ERROR:  type of parameter 5 (numeric) does not match that when preparing the plan (integer)
 CONTEXT:  SQL statement "select pg_typeof(r.a)"
diff --git a/src/pl/plpgsql/src/expected/plpgsql_cache_1.out b/src/pl/plpgsql/src/expected/plpgsql_cache_1.out
index 2a42875747..3b8c73af34 100644
--- a/src/pl/plpgsql/src/expected/plpgsql_cache_1.out
+++ b/src/pl/plpgsql/src/expected/plpgsql_cache_1.out
@@ -3,10 +3,10 @@
 --
 -- These tests logically belong in plpgsql_record.sql, and perhaps someday
 -- can be merged back into it.  For now, however, their results are different
--- depending on debug_invalidate_system_caches_always, so we must have two
--- expected-output files to cover both cases.  To minimize the maintenance
--- effort resulting from that, this file should contain only tests that
--- do have different results under debug_invalidate_system_caches_always.
+-- depending on debug_discard_caches, so we must have two expected-output
+-- files to cover both cases.  To minimize the maintenance effort resulting
+-- from that, this file should contain only tests that do have different
+-- results under debug_discard_caches.
 --
 -- check behavior with changes of a named rowtype
 create table c_mutable(f1 int, f2 text);
@@ -21,7 +21,7 @@ select c_sillyaddone(42);
 alter table c_mutable drop column f1;
 alter table c_mutable add column f1 float8;
 -- currently, this fails due to cached plan for "r.f1 + 1" expression
--- (but if debug_invalidate_system_caches_always is on, it will succeed)
+-- (but if debug_discard_caches is on, it will succeed)
 select c_sillyaddone(42);
  c_sillyaddone
 ---------------
@@ -55,7 +55,7 @@ select show_result_type('select 1 as a');
 (1 row)

 -- currently this fails due to cached plan for pg_typeof expression
--- (but if debug_invalidate_system_caches_always is on, it will succeed)
+-- (but if debug_discard_caches is on, it will succeed)
 select show_result_type('select 2.0 as a');
     show_result_type
 ------------------------
diff --git a/src/pl/plpgsql/src/expected/plpgsql_record.out b/src/pl/plpgsql/src/expected/plpgsql_record.out
index 86d0665924..4c5d95c79e 100644
--- a/src/pl/plpgsql/src/expected/plpgsql_record.out
+++ b/src/pl/plpgsql/src/expected/plpgsql_record.out
@@ -426,7 +426,7 @@ select getf1(row(1,2));
      1
 (1 row)

--- the context stack is different when debug_invalidate_system_caches_always
+-- the context stack is different when debug_discard_caches
 -- is set, so suppress context output
 \set SHOW_CONTEXT never
 select getf1(row(1,2)::two_int8s);
@@ -507,7 +507,7 @@ select sillyaddone(42);
 -- test for change of type of column f1 should be here someday;
 -- for now see plpgsql_cache test
 alter table mutable drop column f1;
--- the context stack is different when debug_invalidate_system_caches_always
+-- the context stack is different when debug_discard_caches
 -- is set, so suppress context output
 \set SHOW_CONTEXT never
 select sillyaddone(42);  -- fail
@@ -527,7 +527,7 @@ select getf3(null::mutable);  -- now it works
 (1 row)

 alter table mutable drop column f3;
--- the context stack is different when debug_invalidate_system_caches_always
+-- the context stack is different when debug_discard_caches
 -- is set, so suppress context output
 \set SHOW_CONTEXT never
 select getf3(null::mutable);  -- fails again
@@ -552,7 +552,7 @@ select sillyaddtwo(42);
 (1 row)

 drop table mutable2;
--- the context stack is different when debug_invalidate_system_caches_always
+-- the context stack is different when debug_discard_caches
 -- is set, so suppress context output
 \set SHOW_CONTEXT never
 select sillyaddtwo(42);  -- fail
diff --git a/src/pl/plpgsql/src/sql/plpgsql_cache.sql b/src/pl/plpgsql/src/sql/plpgsql_cache.sql
index 061f674c9a..a48f9b2afa 100644
--- a/src/pl/plpgsql/src/sql/plpgsql_cache.sql
+++ b/src/pl/plpgsql/src/sql/plpgsql_cache.sql
@@ -3,10 +3,10 @@
 --
 -- These tests logically belong in plpgsql_record.sql, and perhaps someday
 -- can be merged back into it.  For now, however, their results are different
--- depending on debug_invalidate_system_caches_always, so we must have two
--- expected-output files to cover both cases.  To minimize the maintenance
--- effort resulting from that, this file should contain only tests that
--- do have different results under debug_invalidate_system_caches_always.
+-- depending on debug_discard_caches, so we must have two expected-output
+-- files to cover both cases.  To minimize the maintenance effort resulting
+-- from that, this file should contain only tests that do have different
+-- results under debug_discard_caches.
 --

 -- check behavior with changes of a named rowtype
@@ -20,7 +20,7 @@ alter table c_mutable drop column f1;
 alter table c_mutable add column f1 float8;

 -- currently, this fails due to cached plan for "r.f1 + 1" expression
--- (but if debug_invalidate_system_caches_always is on, it will succeed)
+-- (but if debug_discard_caches is on, it will succeed)
 select c_sillyaddone(42);

 -- but it's OK if we force plan rebuilding
@@ -42,7 +42,7 @@ $$;

 select show_result_type('select 1 as a');
 -- currently this fails due to cached plan for pg_typeof expression
--- (but if debug_invalidate_system_caches_always is on, it will succeed)
+-- (but if debug_discard_caches is on, it will succeed)
 select show_result_type('select 2.0 as a');

 -- but it's OK if we force plan rebuilding
diff --git a/src/pl/plpgsql/src/sql/plpgsql_record.sql b/src/pl/plpgsql/src/sql/plpgsql_record.sql
index 722048c730..535a3407a4 100644
--- a/src/pl/plpgsql/src/sql/plpgsql_record.sql
+++ b/src/pl/plpgsql/src/sql/plpgsql_record.sql
@@ -257,7 +257,7 @@ create function getf1(x record) returns int language plpgsql as
 $$ begin return x.f1; end $$;
 select getf1(1);
 select getf1(row(1,2));
--- the context stack is different when debug_invalidate_system_caches_always
+-- the context stack is different when debug_discard_caches
 -- is set, so suppress context output
 \set SHOW_CONTEXT never
 select getf1(row(1,2)::two_int8s);
@@ -316,7 +316,7 @@ select sillyaddone(42);
 -- for now see plpgsql_cache test

 alter table mutable drop column f1;
--- the context stack is different when debug_invalidate_system_caches_always
+-- the context stack is different when debug_discard_caches
 -- is set, so suppress context output
 \set SHOW_CONTEXT never
 select sillyaddone(42);  -- fail
@@ -328,7 +328,7 @@ select getf3(null::mutable);  -- doesn't work yet
 alter table mutable add column f3 int;
 select getf3(null::mutable);  -- now it works
 alter table mutable drop column f3;
--- the context stack is different when debug_invalidate_system_caches_always
+-- the context stack is different when debug_discard_caches
 -- is set, so suppress context output
 \set SHOW_CONTEXT never
 select getf3(null::mutable);  -- fails again
@@ -346,7 +346,7 @@ select sillyaddtwo(42);  -- fail
 create table mutable2(f1 int, f2 text);
 select sillyaddtwo(42);
 drop table mutable2;
--- the context stack is different when debug_invalidate_system_caches_always
+-- the context stack is different when debug_discard_caches
 -- is set, so suppress context output
 \set SHOW_CONTEXT never
 select sillyaddtwo(42);  -- fail
diff --git a/src/test/isolation/specs/deadlock-soft-2.spec b/src/test/isolation/specs/deadlock-soft-2.spec
index 5b7d3db503..26d9c62988 100644
--- a/src/test/isolation/specs/deadlock-soft-2.spec
+++ b/src/test/isolation/specs/deadlock-soft-2.spec
@@ -38,6 +38,6 @@ step s4c    { COMMIT; }
 # The expected output for this test assumes that isolationtester will
 # detect step s1b as waiting before the deadlock detector runs and
 # releases s1 from its blocked state.  To ensure that happens even in
-# very slow (CLOBBER_CACHE_ALWAYS) cases, apply a (*) annotation.
+# very slow (debug_discard_caches) cases, apply a (*) annotation.

 permutation s1a s2a s2b s3a s4a s1b(*) s1c s2c s3c s4c