Doc: Correct description of amcheck example query.

The amcheck documentation incorrectly claimed that its example query
verifies every catalog index in the database.  In fact, the query only
verifies the 10 largest indexes (as determined by pg_class.relpages).
Adjust the description accordingly.

Backpatch: 10-, where contrib/amcheck was introduced.

diff --git a/doc/src/sgml/amcheck.sgml b/doc/src/sgml/amcheck.sgml
index dd71dbd679b191d2078f3ffed370e48a30b3075e..fc0ade5b801e75e8d0de84b5390cbf004bdc6271 100644 (file)
--- a/doc/src/sgml/amcheck.sgml
+++ b/doc/src/sgml/amcheck.sgml
@@ -35,7 +35,7 @@
   functions.
  
  
-  amcheck functions may be used only by superusers.
+  amcheck functions may only be used by superusers.
  
 
  
@@ -81,13 +81,12 @@ ORDER BY c.relpages DESC LIMIT 10;
                 | pg_amop_fam_strat_index         |        5
 (10 rows)
 
-      This example shows a session that performs verification of every
-      catalog index in the database test.  Details of just
-      the 10 largest indexes verified are displayed.  Since no error
-      is raised, all indexes tested appear to be logically consistent.
-      Naturally, this query could easily be changed to call
-      bt_index_check for every index in the
-      database where verification is supported.
+      This example shows a session that performs verification of the
+      10 largest catalog indexes in the database test.
+      Since no error is raised, all indexes tested appear to be
+      logically consistent.  Naturally, this query could easily be
+      changed to call bt_index_check for every
+      index in the database where verification is supported.
      
      
       bt_index_check acquires an AccessShareLock
@@ -230,8 +229,7 @@ ORDER BY c.relpages DESC LIMIT 10;
    
    
     
-     Corruption caused by faulty RAM, and the broader memory subsystem
-     and operating system.
+     Corruption caused by faulty RAM, or the broader memory subsystem.
     
     
      PostgreSQL does not protect against correctable