doc: Fix some grammar and inconsistent tags

Author: Ekaterina Kiryanova, Elena Indrupskaya, Oleg Sibiryakov, Maxim
Yablokov
Discussion: https://postgr.es/m/4c2a430b-32e2-44e2-aeca-03b7db6824e4@postgrespro.ru

diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index d3458840fbecd87ebfbd3d338aa7c9b9ef0042ca..3ec7391ec5e6b769622f59d30344b85bdaa8d22d 100644 (file)
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -7943,7 +7943,8 @@ SCRAM-SHA-256$<iteration count>:&l
        disk and apply at once after the transaction is committed on the
        publisher and received by the subscriber,
        p = apply changes directly using a parallel apply
-       worker if available (same as 't' if no worker is available)
+       worker if available (same as t if no worker is
+       available)
       
      
 

diff --git a/doc/src/sgml/custom-rmgr.sgml b/doc/src/sgml/custom-rmgr.sgml
index baf86b1c07dc126bc0bf6cb8278d5a96c65d4a30..0d982292951ea5b577d2b1f33cc6553314688ad3 100644 (file)
--- a/doc/src/sgml/custom-rmgr.sgml
+++ b/doc/src/sgml/custom-rmgr.sgml
@@ -96,8 +96,8 @@ extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);
  
  
    
-    The extension must remain in shared_preload_libraries as long as any
-    custom WAL records may exist in the system. Otherwise
+    The extension must remain in shared_preload_libraries
+    as long as any custom WAL records may exist in the system. Otherwise
     PostgreSQL will not be able to apply or decode
     the custom WAL records, which may prevent the server from starting.
    

diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index 54de81158b5417ba4a47e85337548c8ae02f6bfd..25c62d7636755954f507d44b2a5664ca313dc17a 100644 (file)
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -1506,9 +1506,9 @@ EXEC SQL TYPE serial_t IS long;
      
 
      
-      Any word you declare as a typedef cannot be used as an SQL keyword
-      in EXEC SQL commands later in the same program.
-      For example, this won't work:
+      Any word you declare as a typedef cannot be used as
+      an SQL keyword in EXEC SQL commands later in the same
+      program. For example, this won't work:
 
 EXEC SQL BEGIN DECLARE SECTION;
     typedef int start;

diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index f4b1f811899fe68e133f68196cea62899e37e940..8e0b2705d34e2c130159b707b38205fb30376bde 100644 (file)
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -2743,8 +2743,8 @@ ninja install
        
         The default backend Meson uses is ninja and that should suffice for
         most use cases.  However, if you'd like to fully integrate with Visual
-        Studio, you can set the <option>BACKEND> to
-        <command>vs>.
+        Studio, you can set the <replaceable>BACKEND> to
+        <literal>vs>.
        
       
      

diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index cbd3aa804f77b73e29b61f654a4614bf2ce6f635..5af016cfa956e9fe99ccfd50f2af562e60ec041d 100644 (file)
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -326,11 +326,12 @@ postgres=# select * from pg_logical_slot_get_changes('regression_slot', NULL, NU
      will work but only while the connection is alive (for example a node
      restart would break it). Then, the primary may delete system catalog rows
      that could be needed by the logical decoding on the standby (as it does
-     not know about the catalog_xmin on the standby). Existing logical slots
-     on standby also get invalidated if wal_level on the
-     primary is reduced to less than logical.
+     not know about the catalog_xmin on the standby).
+     Existing logical slots on standby also get invalidated if
+     wal_level on the primary is reduced to less than
+     logical.
      This is done as soon as the standby detects such a change in the WAL stream.
-     It means that, for walsenders which are lagging (if any), some WAL records up
+     It means that, for walsenders that are lagging (if any), some WAL records up
      to the wal_level parameter change on the primary won't be
      decoded.
     

diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index b11d9a6ba355e66184d61e02d90ebeaa8907c5a5..3f854000f41e0eb199f986579232b25bc9538d16 100644 (file)
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2437,11 +2437,12 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
            Int32
            
             
-             The standby's current global xmin, excluding the catalog_xmin from any
-             replication slots. If both this value and the following
-             catalog_xmin are 0 this is treated as a notification that hot standby
-             feedback will no longer be sent on this connection. Later non-zero
-             messages may reinitiate the feedback mechanism.
+             The standby's current global xmin, excluding the
+             catalog_xmin from any replication slots. If both
+             this value and the following catalog_xmin
+             are 0, this is treated as a notification that hot standby feedback
+             will no longer be sent on this connection. Later non-zero messages
+             may reinitiate the feedback mechanism.
             
            
           
@@ -2450,7 +2451,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
            Int32
            
             
-             The epoch of the global xmin xid on the standby.
+             The epoch of the global xmin xid on the standby.
             
            
           
@@ -2459,8 +2460,9 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
            Int32
            
             
-             The lowest catalog_xmin of any replication slots on the standby. Set to 0
-             if no catalog_xmin exists on the standby or if hot standby feedback is being
+             The lowest catalog_xmin of any replication
+             slots on the standby. Set to 0 if no catalog_xmin
+             exists on the standby or if hot standby feedback is being
              disabled.
             
            
@@ -2470,7 +2472,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
            Int32
            
             
-             The epoch of the catalog_xmin xid on the standby.
+             The epoch of the catalog_xmin xid on the standby.
             
            
           

diff --git a/doc/src/sgml/xact.sgml b/doc/src/sgml/xact.sgml
index b467660eeec15b84ef3833510f42d38d74c70bc4..1813cd0774800cf9905619740654ad191e97927c 100644 (file)
--- a/doc/src/sgml/xact.sgml
+++ b/doc/src/sgml/xact.sgml
@@ -70,7 +70,7 @@
   
 
   
-   In addition to vxid and <type>xid>,
+   In addition to vxid and <literal>xid>,
    prepared transactions are also assigned Global Transaction
    Identifiers (GID). GIDs are string literals up
    to 200 bytes long, which must be unique amongst other currently
@@ -121,7 +121,7 @@
   
    Subtransactions can be started explicitly using the
    SAVEPOINT command, but can also be started in
-   other ways, such as PL/pgSQL's <command>EXCEPTION> clause.
+   other ways, such as PL/pgSQL's <literal>EXCEPTION> clause.
    PL/Python and PL/TCL also support explicit subtransactions.
    Subtransactions can also be started from other subtransactions.
    The top-level transaction and its child subtransactions form a