From 8128b0c152a67917535f50738ac26da4f984ddd9 Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Tue, 14 Apr 2020 14:45:43 +0900 Subject: [PATCH] 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 | 2 +- doc/src/sgml/monitoring.sgml | 8 ++++---- doc/src/sgml/perform.sgml | 2 +- doc/src/sgml/ref/create_publication.sgml | 2 +- doc/src/sgml/ref/pg_verifybackup.sgml | 2 +- doc/src/sgml/ref/psql-ref.sgml | 16 ++++++++-------- doc/src/sgml/ref/select.sgml | 2 +- src/backend/executor/nodeIncrementalSort.c | 22 +++++++++++----------- src/backend/replication/logical/relation.c | 2 +- src/backend/utils/sort/tuplesort.c | 2 +- src/include/utils/tuplesort.h | 2 +- 11 files changed, 31 insertions(+), 31 deletions(-) diff --git a/doc/src/sgml/auto-explain.sgml b/doc/src/sgml/auto-explain.sgml index d4d29c4a64..192d6574c3 100644 --- a/doc/src/sgml/auto-explain.sgml +++ b/doc/src/sgml/auto-explain.sgml @@ -200,7 +200,7 @@ LOAD 'auto_explain'; auto_explain.log_settings 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 c50b72137f..6562cc400b 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 datname name - Name of this database, or NULL for the shared + Name of this database, or NULL for shared objects. numbackends integer Number of backends currently connected to this database, or - NULL for the shared objects. This is the only column + NULL 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. @@ -2725,7 +2725,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i The pg_stat_database 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. @@ -4483,7 +4483,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid, is taking a base backup, the pg_stat_progress_basebackup view will contain a row for each WAL sender process that is currently - running BASE_BACKUP replication command + running the BASE_BACKUP replication command and streaming the backup. The tables below describe the information that will be reported and provide information about how to interpret it. diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml index 0dfc3e80e2..f448abd073 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) - 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 incremental sort step: diff --git a/doc/src/sgml/ref/create_publication.sgml b/doc/src/sgml/ref/create_publication.sgml index 2c52a8aada..473bfb6e56 100644 --- a/doc/src/sgml/ref/create_publication.sgml +++ b/doc/src/sgml/ref/create_publication.sgml @@ -132,7 +132,7 @@ CREATE PUBLICATION name 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. diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml index 8341dfda74..4f9759414f 100644 --- a/doc/src/sgml/ref/pg_verifybackup.sgml +++ b/doc/src/sgml/ref/pg_verifybackup.sgml @@ -41,7 +41,7 @@ PostgreSQL documentation - 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 pg_verifybackup 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 0595d1c04b..de303c8814 100644 --- a/doc/src/sgml/ref/psql-ref.sgml +++ b/doc/src/sgml/ref/psql-ref.sgml @@ -1242,9 +1242,9 @@ testdb=> Lists operator classes (see ). - If access-method-patttern + If access-method-pattern is specified, only operator classes associated with access methods whose - names match pattern are listed. + names match the pattern are listed. If input-type-pattern is specified, only operator classes associated with input types whose names match the pattern are listed. @@ -1265,9 +1265,9 @@ testdb=> Lists operator families (see ). - If access-method-patttern + If access-method-pattern is specified, only operator families associated with access methods whose - names match pattern are listed. + names match the pattern are listed. If input-type-pattern is specified, only operator families associated with input types whose names match the pattern are listed. @@ -1289,9 +1289,9 @@ testdb=> Lists operators associated with operator families (). - If access-method-patttern + If access-method-pattern 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 input-type-pattern is specified, only members of operator families whose names match the pattern are listed. @@ -1312,9 +1312,9 @@ testdb=> Lists procedures associated with operator families (). - If access-method-patttern + If access-method-pattern 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 input-type-pattern 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 2b11c38087..91388151ad 100644 --- a/doc/src/sgml/ref/select.sgml +++ b/doc/src/sgml/ref/select.sgml @@ -1450,7 +1450,7 @@ FETCH { FIRST | NEXT } [ count ] { omitted in a FETCH clause, it defaults to 1. The WITH TIES option is used to return any additional rows that tie for the last place in the result set according to - ORDER BY clause; ORDER BY + the ORDER BY clause; ORDER BY is mandatory in this case. ROW and ROWS as well as FIRST and NEXT are noise diff --git a/src/backend/executor/nodeIncrementalSort.c b/src/backend/executor/nodeIncrementalSort.c index bcab7c054c..39ba11cdf7 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 2e7b755aeb..fec39354c0 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 cc33a85731..de38c6c7e0 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 04d263228d..d992b4875a 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