Fix typos and grammar in documentation and code comments
authorMichael Paquier
Fri, 9 Apr 2021 04:53:22 +0000 (13:53 +0900)
committerMichael Paquier
Fri, 9 Apr 2021 04:53:22 +0000 (13:53 +0900)
Comment fixes are applied on HEAD, and documentation improvements are
applied on back-branches where needed.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20210408164008[email protected]
Backpatch-through: 9.6

doc/src/sgml/maintenance.sgml
doc/src/sgml/ref/create_table.sgml
doc/src/sgml/ref/createuser.sgml

index 38952ba83996eccd8039e3e3ede8c09ef5ec0cb1..de71cb456a5de22f586f4285148ed6cf370661f1 100644 (file)
     never issue VACUUM FULL.  In this approach, the idea
     is not to keep tables at their minimum size, but to maintain steady-state
     usage of disk space: each table occupies space equivalent to its
-    minimum size plus however much space gets used up between vacuumings.
+    minimum size plus however much space gets used up between vacuum runs.
     Although VACUUM FULL can be used to shrink a table back
     to its minimum size and return the disk space to the operating system,
     there is not much point in this if the table will just grow again in the
index 9b349eee3cc4517b86a6f700e447cada6e3e4a3f..e1e9b7db20464e9602e5035fbf32657ab09d533f 100644 (file)
@@ -1478,7 +1478,7 @@ WITH ( MODULUS numeric_literal, REM
     
    
 
-   
+   cuum-scale-factor" xreflabel="autovacuum_vacuum_scale_factor">
     autovacuum_vacuum_scale_factortoast.autovacuum_vacuum_scale_factor (floating point)
     
      autovacuum_vacuum_scale_factor 
@@ -1538,7 +1538,7 @@ WITH ( MODULUS numeric_literal, REM
     
    
 
-   
+   cuum-cost-limit" xreflabel="autovacuum_vacuum_cost_limit">
     autovacuum_vacuum_cost_limittoast.autovacuum_vacuum_cost_limit (integer)
     
      autovacuum_vacuum_cost_limit
index 9d24df8b7a8879e5e3de695f943eced5dd1ebbe4..f43b4a4adaa3074b71f32107e584cbf8aef37e0d 100644 (file)
@@ -44,7 +44,7 @@ PostgreSQL documentation
    If you wish to create a new superuser, you must connect as a
    superuser, not merely with CREATEROLE privilege.
    Being a superuser implies the ability to bypass all access permission
-   checks within the database, so superuserdom should not be granted lightly.
+   checks within the database, so superuser access should not be granted lightly.