Doc: copy-editing for debug_invalidate_system_caches_always description.
authorTom Lane
Sat, 8 May 2021 15:33:13 +0000 (11:33 -0400)
committerTom Lane
Sat, 8 May 2021 15:33:13 +0000 (11:33 -0400)
I came to fix "useful only useful", but the more I looked at the text
the more things I thought could be improved.

doc/src/sgml/config.sgml

index 5efbfe97b5d95d6be8501170df35062873f01b64..a71c8821f6a80a2f5810b3c8289cfe712d17b9e9 100644 (file)
@@ -10406,28 +10406,29 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
       
       
        
-        When set to 1, each cache lookup for a system catalog entry is
-        invalidated at the first possible opportunity, irrespective of whether
+        When set to 1, each system catalog cache entry is
+        invalidated at the first possible opportunity, whether or not
         anything that would render it invalid really occurred.  Caching of
         system catalogs is effectively disabled as a result, so the server
         will run extremely slowly.  Higher values run the cache invalidation
-        recursively, which is even slower and useful only useful for testing
-        in very specific scenarios.
+        recursively, which is even slower and only useful for testing
+        the caching logic itself.  The default value of 0
+        selects normal catalog caching behavior.
        
 
        
-        This option can be very helpful when trying to trigger
-        hard-to-reproduce bugs involving concurrency and catalog changes but
+        This parameter can be very helpful when trying to trigger
+        hard-to-reproduce bugs involving concurrent catalog changes, but it
         is otherwise rarely needed.  See the source code files
         inval.c and
         pg_config_manual.h for details.
        
 
        
-        This setting is supported but off by default (0) when
-        CLOBBER_CACHE_ENABLED is defined at compile time
+        This parameter is supported when
+        CLOBBER_CACHE_ENABLED was defined at compile time
         (which happens automatically when using the
-        <literal>configure> option
+        <application>configure> option
         ).  In production builds, its value
         will always be 0 and attempts to set it to another
         value will raise an error.