Fix collection of typos and grammar mistakes in the tree, volume 2

This fixes some comments and documentation new as of Postgres 13, and is
a follow-up of the work done in dd0f37e.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20200408165653.GF2228@telsasoft.com

doc/src/sgml/auto-explain.sgml

@@ -200,7 +200,7 @@ LOAD 'auto_explain';
     <listitem>
      <para>
       <varname>auto_explain.log_settings</varname> controls whether information
-      about modified configuration options are printed when execution plan is logged.
+      about modified configuration options is printed when execution plan is logged.
       Only options affecting query planning with value different from the built-in
       default value are included in the output.  This parameter is off by default.
       Only superusers can change this setting.

doc/src/sgml/monitoring.sgml

@@ -2596,14 +2596,14 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
     <row>
      <entry><structfield>datname</structfield></entry>
      <entry><type>name</type></entry>
-     <entry>Name of this database, or <literal>NULL</literal> for the shared
+     <entry>Name of this database, or <literal>NULL</literal> for shared
      objects.</entry>
     </row>
     <row>
      <entry><structfield>numbackends</structfield></entry>
      <entry><type>integer</type></entry>
      <entry>Number of backends currently connected to this database, or
-     <literal>NULL</literal> for the shared objects.  This is the only column
+     <literal>NULL</literal> for shared objects.  This is the only column
      in this view that returns a value reflecting current state; all other
      columns return the accumulated values since the last reset.</entry>
     </row>
@@ -2725,7 +2725,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
 
   <para>
    The <structname>pg_stat_database</structname> view will contain one row
-   for each database in the cluster, plus one for the shared objects, showing
+   for each database in the cluster, plus one for shared objects, showing
    database-wide statistics.
   </para>
 
@@ -4483,7 +4483,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
    is taking a base backup, the
    <structname>pg_stat_progress_basebackup</structname>
    view will contain a row for each WAL sender process that is currently
-   running <command>BASE_BACKUP</command> replication command
+   running the <command>BASE_BACKUP</command> replication command
    and streaming the backup. The tables below describe the information
    that will be reported and provide information about how to interpret it.
   </para>

doc/src/sgml/perform.sgml

@@ -311,7 +311,7 @@ EXPLAIN SELECT * FROM tenk1 ORDER BY unique1;
    ->  Seq Scan on tenk1  (cost=0.00..445.00 rows=10000 width=244)
 </screen>
 
-    If the a part of the plan guarantess an ordering on a prefix of the
+    If a part of the plan guarantees an ordering on a prefix of the
     required sort keys, then the planner may instead decide to use an
     <literal>incremental sort</literal> step:
 

doc/src/sgml/ref/create_publication.sgml

@@ -132,7 +132,7 @@ CREATE PUBLICATION <replaceable class="parameter">name</replaceable>
           on its partitions) contained in the publication will be published
           using the identity and schema of the partitioned table rather than
           that of the individual partitions that are actually changed; the
-          latter is the default.  Enablings this allows the changes to be
+          latter is the default.  Enabling this allows the changes to be
           replicated into a non-partitioned table or a partitioned table
           consisting of a different set of partitions.
          </para>

doc/src/sgml/ref/pg_verifybackup.sgml

@@ -41,7 +41,7 @@ PostgreSQL documentation
   </para>
 
   <para>
-   It is important to note that that the validation which is performed by
+   It is important to note that the validation which is performed by
    <application>pg_verifybackup</application> does not and can not include
    every check which will be performed by a running server when attempting
    to make use of the backup. Even if you use this tool, you should still

doc/src/sgml/ref/psql-ref.sgml

@@ -1242,9 +1242,9 @@ testdb=>
         <para>
         Lists operator classes
         (see <xref linkend="catalog-pg-opclass"/>).
-        If <replaceable class="parameter">access-method-patttern</replaceable>
+        If <replaceable class="parameter">access-method-pattern</replaceable>
         is specified, only operator classes associated with access methods whose
-        names match pattern are listed.
+        names match the pattern are listed.
         If <replaceable class="parameter">input-type-pattern</replaceable>
         is specified, only operator classes associated with input types whose
         names match the pattern are listed.
@@ -1265,9 +1265,9 @@ testdb=&gt;
         <para>
         Lists operator families
         (see <xref linkend="catalog-pg-opfamily"/>).
-        If <replaceable class="parameter">access-method-patttern</replaceable>
+        If <replaceable class="parameter">access-method-pattern</replaceable>
         is specified, only operator families associated with access methods whose
-        names match pattern are listed.
+        names match the pattern are listed.
         If <replaceable class="parameter">input-type-pattern</replaceable>
         is specified, only operator families associated with input types whose
         names match the pattern are listed.
@@ -1289,9 +1289,9 @@ testdb=&gt;
         <para>
         Lists operators associated with operator families
         (<xref linkend="catalog-pg-amop"/>).
-        If <replaceable class="parameter">access-method-patttern</replaceable>
+        If <replaceable class="parameter">access-method-pattern</replaceable>
         is specified, only members of operator families associated with access
-        methods whose names match pattern are listed.
+        methods whose names match the pattern are listed.
         If <replaceable class="parameter">input-type-pattern</replaceable>
         is specified, only members of operator families whose names match the
         pattern are listed.
@@ -1312,9 +1312,9 @@ testdb=&gt;
         <para>
         Lists procedures associated with operator families
         (<xref linkend="catalog-pg-amproc"/>).
-        If <replaceable class="parameter">access-method-patttern</replaceable>
+        If <replaceable class="parameter">access-method-pattern</replaceable>
         is specified, only members of operator families associated with access
-        methods whose names match pattern are listed.
+        methods whose names match the pattern are listed.
         If <replaceable class="parameter">input-type-pattern</replaceable>
         is specified, only members of operator families whose names match the
         pattern are listed.

doc/src/sgml/ref/select.sgml

@@ -1450,7 +1450,7 @@ FETCH { FIRST | NEXT } [ <replaceable class="parameter">count</replaceable> ] {
     omitted in a <literal>FETCH</literal> clause, it defaults to 1.
     The <literal>WITH TIES</literal> option is used to return any additional
     rows that tie for the last place in the result set according to
-    <literal>ORDER BY</literal> clause; <literal>ORDER BY</literal>
+    the <literal>ORDER BY</literal> clause; <literal>ORDER BY</literal>
     is mandatory in this case.
     <literal>ROW</literal> and <literal>ROWS</literal> as well as
     <literal>FIRST</literal> and <literal>NEXT</literal> are noise

src/backend/executor/nodeIncrementalSort.c

@@ -270,7 +270,7 @@ isCurrentGroup(IncrementalSortState *node, TupleTableSlot *pivot, TupleTableSlot
  * verify they're all part of the same prefix key group before sorting them
  * solely by unsorted suffix keys.
  *
- * While it's likely that all already fetch tuples are all part of a single
+ * While it's likely that all tuples already fetched are all part of a single
  * prefix group, we also have to handle the possibility that there is at least
  * one different prefix key group before the large prefix key group.
  * ----------------------------------------------------------------
@@ -381,7 +381,7 @@ switchToPresortedPrefixMode(PlanState *pstate)
 				 * node->transfer_tuple slot, and, even though that slot
 				 * points to memory inside the full sort tuplesort, we can't
 				 * reset that tuplesort anyway until we've fully transferred
-				 * out of its tuples, so this reference is safe. We do need to
+				 * out its tuples, so this reference is safe. We do need to
 				 * reset the group pivot tuple though since we've finished the
 				 * current prefix key group.
 				 */
@@ -603,7 +603,7 @@ ExecIncrementalSort(PlanState *pstate)
 			/*
 			 * Initialize presorted column support structures for
 			 * isCurrentGroup(). It's correct to do this along with the
-			 * initial intialization for the full sort state (and not for the
+			 * initial initialization for the full sort state (and not for the
 			 * prefix sort state) since we always load the full sort state
 			 * first.
 			 */
@@ -723,7 +723,7 @@ ExecIncrementalSort(PlanState *pstate)
 				nTuples++;
 
 				/*
-				 * If we've reach our minimum group size, then we need to
+				 * If we've reached our minimum group size, then we need to
 				 * store the most recent tuple as a pivot.
 				 */
 				if (nTuples == minGroupSize)
@@ -752,7 +752,7 @@ ExecIncrementalSort(PlanState *pstate)
 				{
 					/*
 					 * Since the tuple we fetched isn't part of the current
-					 * prefix key group we don't want to  sort it as part of
+					 * prefix key group we don't want to sort it as part of
 					 * the current batch. Instead we use the group_pivot slot
 					 * to carry it over to the next batch (even though we
 					 * won't actually treat it as a group pivot).
@@ -792,12 +792,12 @@ ExecIncrementalSort(PlanState *pstate)
 			}
 
 			/*
-			 * Unless we've alrady transitioned modes to reading from the full
+			 * Unless we've already transitioned modes to reading from the full
 			 * sort state, then we assume that having read at least
 			 * DEFAULT_MAX_FULL_SORT_GROUP_SIZE tuples means it's likely we're
 			 * processing a large group of tuples all having equal prefix keys
 			 * (but haven't yet found the final tuple in that prefix key
-			 * group), so we need to transition in to presorted prefix mode.
+			 * group), so we need to transition into presorted prefix mode.
 			 */
 			if (nTuples > DEFAULT_MAX_FULL_SORT_GROUP_SIZE &&
 				node->execution_status != INCSORT_READFULLSORT)
@@ -849,7 +849,7 @@ ExecIncrementalSort(PlanState *pstate)
 
 				/*
 				 * We might have multiple prefix key groups in the full sort
-				 * state, so the mode transition function needs to know the it
+				 * state, so the mode transition function needs to know that it
 				 * needs to move from the fullsort to presorted prefix sort.
 				 */
 				node->n_fullsort_remaining = nTuples;
@@ -913,7 +913,7 @@ ExecIncrementalSort(PlanState *pstate)
 			/*
 			 * If the tuple's prefix keys match our pivot tuple, we're not
 			 * done yet and can load it into the prefix sort state. If not, we
-			 * don't want to  sort it as part of the current batch. Instead we
+			 * don't want to sort it as part of the current batch. Instead we
 			 * use the group_pivot slot to carry it over to the next batch
 			 * (even though we won't actually treat it as a group pivot).
 			 */
@@ -1121,14 +1121,14 @@ ExecReScanIncrementalSort(IncrementalSortState *node)
 	PlanState  *outerPlan = outerPlanState(node);
 
 	/*
-	 * Incremental sort doesn't support efficient rescan even when paramters
+	 * Incremental sort doesn't support efficient rescan even when parameters
 	 * haven't changed (e.g., rewind) because unlike regular sort we don't
 	 * store all tuples at once for the full sort.
 	 *
 	 * So even if EXEC_FLAG_REWIND is set we just reset all of our state and
 	 * reexecute the sort along with the child node below us.
 	 *
-	 * In theory if we've only fill the full sort with one batch (and haven't
+	 * In theory if we've only filled the full sort with one batch (and haven't
 	 * reset it for a new batch yet) then we could efficiently rewind, but
 	 * that seems a narrow enough case that it's not worth handling specially
 	 * at this time.

src/backend/replication/logical/relation.c

@@ -575,7 +575,7 @@ logicalrep_partmap_init(void)
  * Returned entry reuses most of the values of the root table's entry, save
  * the attribute map, which can be different for the partition.
  *
- * Note there's no logialrep_partition_close, because the caller closes the
+ * Note there's no logicalrep_partition_close, because the caller closes the
  * the component relation.
  */
 LogicalRepRelMapEntry *

src/backend/utils/sort/tuplesort.c

@@ -808,7 +808,7 @@ tuplesort_begin_common(int workMem, SortCoordinate coordinate,
  *
  * Setup, or reset, all state need for processing a new set of tuples with this
  * sort state. Called both from tuplesort_begin_common (the first time sorting
- * with this sort state) and tuplesort_reseti (for subsequent usages).
+ * with this sort state) and tuplesort_reset (for subsequent usages).
  */
 static void
 tuplesort_begin_batch(Tuplesortstate *state)

src/include/utils/tuplesort.h

@@ -63,7 +63,7 @@ typedef struct SortCoordinateData *SortCoordinate;
  * sometimes put it in shared memory.
  *
  * The parallel-sort infrastructure relies on having a zero TuplesortMethod
- * indicate that a worker never did anything, so we assign zero to
+ * to indicate that a worker never did anything, so we assign zero to
  * SORT_TYPE_STILL_IN_PROGRESS.  The other values of this enum can be
  * OR'ed together to represent a situation where different workers used
  * different methods, so we need a separate bit for each one.  Keep the