aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--doc/src/sgml/auto-explain.sgml2
-rw-r--r--doc/src/sgml/monitoring.sgml8
-rw-r--r--doc/src/sgml/perform.sgml2
-rw-r--r--doc/src/sgml/ref/create_publication.sgml2
-rw-r--r--doc/src/sgml/ref/pg_verifybackup.sgml2
-rw-r--r--doc/src/sgml/ref/psql-ref.sgml16
-rw-r--r--doc/src/sgml/ref/select.sgml2
-rw-r--r--src/backend/executor/nodeIncrementalSort.c22
-rw-r--r--src/backend/replication/logical/relation.c2
-rw-r--r--src/backend/utils/sort/tuplesort.c2
-rw-r--r--src/include/utils/tuplesort.h2
11 files changed, 31 insertions, 31 deletions
diff --git a/doc/src/sgml/auto-explain.sgml b/doc/src/sgml/auto-explain.sgml
index d4d29c4a649..192d6574c30 100644
--- a/doc/src/sgml/auto-explain.sgml
+++ b/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.
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index c50b72137f3..6562cc400b3 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/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>
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index 0dfc3e80e29..f448abd0730 100644
--- a/doc/src/sgml/perform.sgml
+++ b/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:
diff --git a/doc/src/sgml/ref/create_publication.sgml b/doc/src/sgml/ref/create_publication.sgml
index 2c52a8aada1..473bfb6e56f 100644
--- a/doc/src/sgml/ref/create_publication.sgml
+++ b/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>
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index 8341dfda741..4f9759414f8 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/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
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 0595d1c04b9..de303c88144 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1242,9 +1242,9 @@ testdb=&gt;
<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.
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 2b11c38087f..91388151ad4 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/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
diff --git a/src/backend/executor/nodeIncrementalSort.c b/src/backend/executor/nodeIncrementalSort.c
index bcab7c054c1..39ba11cdf76 100644
--- a/src/backend/executor/nodeIncrementalSort.c
+++ b/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.
diff --git a/src/backend/replication/logical/relation.c b/src/backend/replication/logical/relation.c
index 2e7b755aebb..fec39354c03 100644
--- a/src/backend/replication/logical/relation.c
+++ b/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 *
diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c
index cc33a857314..de38c6c7e0a 100644
--- a/src/backend/utils/sort/tuplesort.c
+++ b/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)
diff --git a/src/include/utils/tuplesort.h b/src/include/utils/tuplesort.h
index 04d263228d4..d992b4875a5 100644
--- a/src/include/utils/tuplesort.h
+++ b/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
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-03 10:14:59 +0000