From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@lists.postgresql.org, Amit Kapila <amit.kapila16@gmail.com>
Subject: Re: typos
Date: Mon, 9 Jan 2023 22:57:22 -0600
Message-ID: <20230110045722.GD9837@telsasoft.com> (raw)
In-Reply-To: <20230103213922.GR1153@telsasoft.com>
References: <20221230231257.GI1153@telsasoft.com>
<Y7PZHbDrRMx5O9Hp@paquier.xyz>
<20230103213922.GR1153@telsasoft.com>
On Tue, Jan 03, 2023 at 03:39:22PM -0600, Justin Pryzby wrote:
> On Tue, Jan 03, 2023 at 04:28:29PM +0900, Michael Paquier wrote:
> > On Fri, Dec 30, 2022 at 05:12:57PM -0600, Justin Pryzby wrote:
> >
> > # Use larger ccache cache, as this task compiles with multiple compilers /
> > # flag combinations
> > - CCACHE_MAXSIZE: "1GB"
> > + CCACHE_MAXSIZE: "1G"
> >
> > In 0006, I am not sure how much this matters. Perhaps somebody more
> > fluent with Cirrus, though, has a different opinion..
>
> It's got almost nothing to do with cirrus. It's an environment
> variable, and we're using a suffix other than what's
> supported/documented by ccache, which only happens to work.
>
> > 0014 and 0013 do not reduce the translation workload, as the messages
> > include some stuff specific to the GUC names accessed to, or some
> > specific details about the code paths triggered.
>
> It seems to matter because otherwise the translators sometimes re-type
> the view name, which (not surprisingly) can get messed up, which is how
> I mentioned having noticed this.
>
> On Tue, Jan 03, 2023 at 05:41:58PM +0900, Michael Paquier wrote:
> > On Tue, Jan 03, 2023 at 01:03:01PM +0530, Amit Kapila wrote:
> > > One minor comment:
> > > - spoken in Belgium (BE), with a <acronym>UTF-8</acronym>
> > > character set
> > > + spoken in Belgium (BE), with a <acronym>UTF</acronym>-8
> > > character set
> > >
> > > Shouldn't this be <acronym>UTF8</acronym> as we are using in
> > > func.sgml?
> >
> > Yeah, I was wondering as well why this change is not worse, which is
> > why I left it out of 33ab0a2. There is an acronym for UTF in
> > acronym.sgml, which makes sense to me, but that's the only place where
> > this is used. To add more on top of that, the docs basically need
> > only UTF8, and we have three references to UTF-16, none of them using
> > the <acronym> markup.
>
> I changed it for consistency, as it's the only thing that says <>UTF-8<>
> anywhere, and charset.sgml already says <>UTF<>-8 elsewhere.
>
> Alternately, I suggest to change charset to say <>UTF8<> in both places.
As attached.
This also fixes "specualtive" in Amit's recent commit.
--
Justin
Attachments:
[text/x-diff] 0001-typos.patch (656B, ../20230110045722.GD9837@telsasoft.com/2-0001-typos.patch)
download | inline diff:
From 8b56d6007e13e3b42bc75da3b9174ecab8a8dd70 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sun, 25 Sep 2022 18:40:36 -0500
Subject: [PATCH 1/9] typos
---
.cirrus.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.cirrus.yml b/.cirrus.ymlindex 69837bcd5ad..048a004e309 100644--- a/.cirrus.yml+++ b/.cirrus.yml@@ -655,7 +655,7 @@ task:
# Use larger ccache cache, as this task compiles with multiple compilers /
# flag combinations
- CCACHE_MAXSIZE: "1GB"+ CCACHE_MAXSIZE: "1G"
CCACHE_DIR: "/tmp/ccache_dir"
LINUX_CONFIGURE_FEATURES: *LINUX_CONFIGURE_FEATURES
--
2.25.1
[text/x-diff] 0002-comments-grammar-extended-and-other-stats.patch (6.9K, ../20230110045722.GD9837@telsasoft.com/3-0002-comments-grammar-extended-and-other-stats.patch)
download | inline diff:
From c082768a857ebd7a0a534ee497761dca0c621f64 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sun, 26 Sep 2021 11:13:27 -0500
Subject: [PATCH 2/9] comments grammar: extended (and other) stats
See:
202109272104.7t253iw236fb@alvherre.pgsql
070d2e19e40897d857f570f24888fc30727ed9c0
609b0652af00374b89411ea2613fd5bb92bca92c
a4d75c86bf15220df22de0a92c819ecef9db3849
7300a699502fe5432b05fbc75baca534b080bebb
ccaa3569f58796868303629bc2d63ddddb599b38
---
src/backend/commands/statscmds.c | 4 ++--
src/backend/statistics/README | 2 +-
src/backend/statistics/dependencies.c | 8 ++++----
src/backend/statistics/extended_stats.c | 4 ++--
src/backend/utils/adt/pgstatfuncs.c | 4 ++--
src/backend/utils/adt/ruleutils.c | 2 +-
src/include/statistics/extended_stats_internal.h | 2 +-
7 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/backend/commands/statscmds.c b/src/backend/commands/statscmds.cindex 26ebd0819d6..2e41745646b 100644--- a/src/backend/commands/statscmds.c+++ b/src/backend/commands/statscmds.c@@ -377,7 +377,7 @@ CreateStatistics(CreateStatsStmt *stmt)
/*
* If no statistic type was specified, build them all (but only when the
- * statistics is defined on more than one column/expression).+ * statistics object is defined on more than one column/expression).
*/
if ((!requested_type) && (numcols >= 2))
{
@@ -432,7 +432,7 @@ CreateStatistics(CreateStatsStmt *stmt)
* similar to why we don't bother with extracting columns from
* expressions. It's either expensive or very easy to defeat for
* determined user, and there's no risk if we allow such statistics (the
- * statistics is useless, but harmless).+ * statistic is useless, but harmless).
*/
foreach(cell, stxexprs)
{
diff --git a/src/backend/statistics/README b/src/backend/statistics/READMEindex 13a97a35662..b87ca4734b2 100644--- a/src/backend/statistics/README+++ b/src/backend/statistics/README@@ -24,7 +24,7 @@ There are currently several kinds of extended statistics:
Compatible clause types
-----------------------
-Each type of statistics may be used to estimate some subset of clause types.+Each type of statistic may be used to estimate some subset of clause types.
(a) functional dependencies - equality clauses (AND), possibly IS NULL
diff --git a/src/backend/statistics/dependencies.c b/src/backend/statistics/dependencies.cindex e6e2835345e..a54e038d6a1 100644--- a/src/backend/statistics/dependencies.c+++ b/src/backend/statistics/dependencies.c@@ -846,7 +846,7 @@ dependency_is_compatible_clause(Node *clause, Index relid, AttrNumber *attnum)
AttrNumber clause_attnum;
/*
- * Had we found incompatible clause in the arguments, treat the+ * If we found an incompatible clause in the arguments, treat the
* whole clause as incompatible.
*/
if (!dependency_is_compatible_clause((Node *) lfirst(lc),
@@ -1274,7 +1274,7 @@ dependency_is_compatible_expression(Node *clause, Index relid, List *statlist, N
Node *or_expr = NULL;
/*
- * Had we found incompatible expression in the arguments, treat+ * If we found an incompatible expression in the arguments, treat
* the whole expression as incompatible.
*/
if (!dependency_is_compatible_expression((Node *) lfirst(lc), relid,
@@ -1725,7 +1725,7 @@ dependencies_clauselist_selectivity(PlannerInfo *root,
/*
* For expressions, we need to do two translations. First
- * we have to translate the negative attnum to index in+ * we have to translate the negative attnum to an index in
* the list of expressions (in the statistics object).
* Then we need to see if there's a matching clause. The
* index of the unique expression determines the attnum
@@ -1733,7 +1733,7 @@ dependencies_clauselist_selectivity(PlannerInfo *root,
*/
idx = -(1 + attnum);
- /* Is the expression index is valid? */+ /* Is the expression index valid? */
Assert((idx >= 0) && (idx < list_length(stat->exprs)));
expr = (Node *) list_nth(stat->exprs, idx);
diff --git a/src/backend/statistics/extended_stats.c b/src/backend/statistics/extended_stats.cindex bdc21bb4577..edc7352562c 100644--- a/src/backend/statistics/extended_stats.c+++ b/src/backend/statistics/extended_stats.c@@ -1214,8 +1214,8 @@ stat_covers_expressions(StatisticExtInfo *stat, List *exprs,
/*
* choose_best_statistics
- * Look for and return statistics with the specified 'requiredkind' which- * have keys that match at least two of the given attnums. Return NULL if+ * Look for and return the statistics object with the specified 'requiredkind' which+ * has keys that match at least two of the given attnums. Return NULL if
* there's no match.
*
* The current selection criteria is very simple - we choose the statistics
diff --git a/src/backend/utils/adt/pgstatfuncs.c b/src/backend/utils/adt/pgstatfuncs.cindex 6cddd74aa76..fb46153d8bb 100644--- a/src/backend/utils/adt/pgstatfuncs.c+++ b/src/backend/utils/adt/pgstatfuncs.c@@ -1749,7 +1749,7 @@ pg_stat_get_archiver(PG_FUNCTION_ARGS)
}
/*
- * Get the statistics for the replication slot. If the slot statistics is not+ * Get the statistics for the replication slot. If the slot statistics are not
* available, return all-zeroes stats.
*/
Datum
@@ -1821,7 +1821,7 @@ pg_stat_get_replication_slot(PG_FUNCTION_ARGS)
/*
* Get the subscription statistics for the given subscription. If the
- * subscription statistics is not available, return all-zeros stats.+ * subscription statistics are not available, return all-zeros stats.
*/
Datum
pg_stat_get_subscription_stats(PG_FUNCTION_ARGS)
diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.cindex 9ac42efdbc3..da59c85d3d5 100644--- a/src/backend/utils/adt/ruleutils.c+++ b/src/backend/utils/adt/ruleutils.c@@ -1699,7 +1699,7 @@ pg_get_statisticsobj_worker(Oid statextid, bool columns_only, bool missing_ok)
* will create all statistics types on a newer postgres version, if
* the statistics had all options enabled on the original version.
*
- * But if the statistics is defined on just a single column, it has to+ * But if the statistics are defined on just a single column, it has to
* be an expression statistics. In that case we don't need to specify
* kinds.
*/
diff --git a/src/include/statistics/extended_stats_internal.h b/src/include/statistics/extended_stats_internal.hindex 7b55eb8ffac..72f94814704 100644--- a/src/include/statistics/extended_stats_internal.h+++ b/src/include/statistics/extended_stats_internal.h@@ -57,7 +57,7 @@ typedef struct SortItem
int count;
} SortItem;
-/* a unified representation of the data the statistics is built on */+/* a unified representation of the data the statistics object is built on */
typedef struct StatsBuildData
{
int numrows;
--
2.25.1
[text/x-diff] 0003-fix-whitespace.patch (13.6K, ../20230110045722.GD9837@telsasoft.com/4-0003-fix-whitespace.patch)
download | inline diff:
From 6a80a46886d3659a3ccd5783fdf16b2ae750d73b Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 23 Jul 2022 15:10:01 -0500
Subject: [PATCH 3/9] fix whitespace
weird since c91560defc57f89f7e88632ea14ae77b5cec78ee
See also:
https://www.postgresql.org/message-id/CAFBsxsHtYvE1Txm+NYM5gB1C3EZN_qDPJOOsJK_VsC2DXqZfcA@mail.gmail.com
---
src/backend/utils/cache/inval.c | 188 ++++++++++++++++----------------
src/backend/utils/mmgr/mcxt.c | 4 +-
2 files changed, 96 insertions(+), 96 deletions(-)
diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.cindex 0008826f67c..cc7de542b1e 100644--- a/src/backend/utils/cache/inval.c+++ b/src/backend/utils/cache/inval.c@@ -3,100 +3,100 @@
* inval.c
* POSTGRES cache invalidation dispatcher code.
*
- * This is subtle stuff, so pay attention:- *- * When a tuple is updated or deleted, our standard visibility rules- * consider that it is *still valid* so long as we are in the same command,- * ie, until the next CommandCounterIncrement() or transaction commit.- * (See access/heap/heapam_visibility.c, and note that system catalogs are- * generally scanned under the most current snapshot available, rather than- * the transaction snapshot.) At the command boundary, the old tuple stops- * being valid and the new version, if any, becomes valid. Therefore,- * we cannot simply flush a tuple from the system caches during heap_update()- * or heap_delete(). The tuple is still good at that point; what's more,- * even if we did flush it, it might be reloaded into the caches by a later- * request in the same command. So the correct behavior is to keep a list- * of outdated (updated/deleted) tuples and then do the required cache- * flushes at the next command boundary. We must also keep track of- * inserted tuples so that we can flush "negative" cache entries that match- * the new tuples; again, that mustn't happen until end of command.- *- * Once we have finished the command, we still need to remember inserted- * tuples (including new versions of updated tuples), so that we can flush- * them from the caches if we abort the transaction. Similarly, we'd better- * be able to flush "negative" cache entries that may have been loaded in- * place of deleted tuples, so we still need the deleted ones too.- *- * If we successfully complete the transaction, we have to broadcast all- * these invalidation events to other backends (via the SI message queue)- * so that they can flush obsolete entries from their caches. Note we have- * to record the transaction commit before sending SI messages, otherwise- * the other backends won't see our updated tuples as good.- *- * When a subtransaction aborts, we can process and discard any events- * it has queued. When a subtransaction commits, we just add its events- * to the pending lists of the parent transaction.- *- * In short, we need to remember until xact end every insert or delete- * of a tuple that might be in the system caches. Updates are treated as- * two events, delete + insert, for simplicity. (If the update doesn't- * change the tuple hash value, catcache.c optimizes this into one event.)- *- * We do not need to register EVERY tuple operation in this way, just those- * on tuples in relations that have associated catcaches. We do, however,- * have to register every operation on every tuple that *could* be in a- * catcache, whether or not it currently is in our cache. Also, if the- * tuple is in a relation that has multiple catcaches, we need to register- * an invalidation message for each such catcache. catcache.c's- * PrepareToInvalidateCacheTuple() routine provides the knowledge of which- * catcaches may need invalidation for a given tuple.- *- * Also, whenever we see an operation on a pg_class, pg_attribute, or- * pg_index tuple, we register a relcache flush operation for the relation- * described by that tuple (as specified in CacheInvalidateHeapTuple()).- * Likewise for pg_constraint tuples for foreign keys on relations.- *- * We keep the relcache flush requests in lists separate from the catcache- * tuple flush requests. This allows us to issue all the pending catcache- * flushes before we issue relcache flushes, which saves us from loading- * a catcache tuple during relcache load only to flush it again right away.- * Also, we avoid queuing multiple relcache flush requests for the same- * relation, since a relcache flush is relatively expensive to do.- * (XXX is it worth testing likewise for duplicate catcache flush entries?- * Probably not.)- *- * Many subsystems own higher-level caches that depend on relcache and/or- * catcache, and they register callbacks here to invalidate their caches.- * While building a higher-level cache entry, a backend may receive a- * callback for the being-built entry or one of its dependencies. This- * implies the new higher-level entry would be born stale, and it might- * remain stale for the life of the backend. Many caches do not prevent- * that. They rely on DDL for can't-miss catalog changes taking- * AccessExclusiveLock on suitable objects. (For a change made with less- * locking, backends might never read the change.) The relation cache,- * however, needs to reflect changes from CREATE INDEX CONCURRENTLY no later- * than the beginning of the next transaction. Hence, when a relevant- * invalidation callback arrives during a build, relcache.c reattempts that- * build. Caches with similar needs could do likewise.- *- * If a relcache flush is issued for a system relation that we preload- * from the relcache init file, we must also delete the init file so that- * it will be rebuilt during the next backend restart. The actual work of- * manipulating the init file is in relcache.c, but we keep track of the- * need for it here.- *- * Currently, inval messages are sent without regard for the possibility- * that the object described by the catalog tuple might be a session-local- * object such as a temporary table. This is because (1) this code has- * no practical way to tell the difference, and (2) it is not certain that- * other backends don't have catalog cache or even relcache entries for- * such tables, anyway; there is nothing that prevents that. It might be- * worth trying to avoid sending such inval traffic in the future, if those- * problems can be overcome cheaply.- *- * When wal_level=logical, write invalidations into WAL at each command end to- * support the decoding of the in-progress transactions. See- * CommandEndInvalidationMessages.+ * This is subtle stuff, so pay attention:+ *+ * When a tuple is updated or deleted, our standard visibility rules+ * consider that it is *still valid* so long as we are in the same command,+ * ie, until the next CommandCounterIncrement() or transaction commit.+ * (See access/heap/heapam_visibility.c, and note that system catalogs are+ * generally scanned under the most current snapshot available, rather than+ * the transaction snapshot.) At the command boundary, the old tuple stops+ * being valid and the new version, if any, becomes valid. Therefore,+ * we cannot simply flush a tuple from the system caches during heap_update()+ * or heap_delete(). The tuple is still good at that point; what's more,+ * even if we did flush it, it might be reloaded into the caches by a later+ * request in the same command. So the correct behavior is to keep a list+ * of outdated (updated/deleted) tuples and then do the required cache+ * flushes at the next command boundary. We must also keep track of+ * inserted tuples so that we can flush "negative" cache entries that match+ * the new tuples; again, that mustn't happen until end of command.+ *+ * Once we have finished the command, we still need to remember inserted+ * tuples (including new versions of updated tuples), so that we can flush+ * them from the caches if we abort the transaction. Similarly, we'd better+ * be able to flush "negative" cache entries that may have been loaded in+ * place of deleted tuples, so we still need the deleted ones too.+ *+ * If we successfully complete the transaction, we have to broadcast all+ * these invalidation events to other backends (via the SI message queue)+ * so that they can flush obsolete entries from their caches. Note we have+ * to record the transaction commit before sending SI messages, otherwise+ * the other backends won't see our updated tuples as good.+ *+ * When a subtransaction aborts, we can process and discard any events+ * it has queued. When a subtransaction commits, we just add its events+ * to the pending lists of the parent transaction.+ *+ * In short, we need to remember until xact end every insert or delete+ * of a tuple that might be in the system caches. Updates are treated as+ * two events, delete + insert, for simplicity. (If the update doesn't+ * change the tuple hash value, catcache.c optimizes this into one event.)+ *+ * We do not need to register EVERY tuple operation in this way, just those+ * on tuples in relations that have associated catcaches. We do, however,+ * have to register every operation on every tuple that *could* be in a+ * catcache, whether or not it currently is in our cache. Also, if the+ * tuple is in a relation that has multiple catcaches, we need to register+ * an invalidation message for each such catcache. catcache.c's+ * PrepareToInvalidateCacheTuple() routine provides the knowledge of which+ * catcaches may need invalidation for a given tuple.+ *+ * Also, whenever we see an operation on a pg_class, pg_attribute, or+ * pg_index tuple, we register a relcache flush operation for the relation+ * described by that tuple (as specified in CacheInvalidateHeapTuple()).+ * Likewise for pg_constraint tuples for foreign keys on relations.+ *+ * We keep the relcache flush requests in lists separate from the catcache+ * tuple flush requests. This allows us to issue all the pending catcache+ * flushes before we issue relcache flushes, which saves us from loading+ * a catcache tuple during relcache load only to flush it again right away.+ * Also, we avoid queuing multiple relcache flush requests for the same+ * relation, since a relcache flush is relatively expensive to do.+ * (XXX is it worth testing likewise for duplicate catcache flush entries?+ * Probably not.)+ *+ * Many subsystems own higher-level caches that depend on relcache and/or+ * catcache, and they register callbacks here to invalidate their caches.+ * While building a higher-level cache entry, a backend may receive a+ * callback for the being-built entry or one of its dependencies. This+ * implies the new higher-level entry would be born stale, and it might+ * remain stale for the life of the backend. Many caches do not prevent+ * that. They rely on DDL for can't-miss catalog changes taking+ * AccessExclusiveLock on suitable objects. (For a change made with less+ * locking, backends might never read the change.) The relation cache,+ * however, needs to reflect changes from CREATE INDEX CONCURRENTLY no later+ * than the beginning of the next transaction. Hence, when a relevant+ * invalidation callback arrives during a build, relcache.c reattempts that+ * build. Caches with similar needs could do likewise.+ *+ * If a relcache flush is issued for a system relation that we preload+ * from the relcache init file, we must also delete the init file so that+ * it will be rebuilt during the next backend restart. The actual work of+ * manipulating the init file is in relcache.c, but we keep track of the+ * need for it here.+ *+ * Currently, inval messages are sent without regard for the possibility+ * that the object described by the catalog tuple might be a session-local+ * object such as a temporary table. This is because (1) this code has+ * no practical way to tell the difference, and (2) it is not certain that+ * other backends don't have catalog cache or even relcache entries for+ * such tables, anyway; there is nothing that prevents that. It might be+ * worth trying to avoid sending such inval traffic in the future, if those+ * problems can be overcome cheaply.+ *+ * When wal_level=logical, write invalidations into WAL at each command end to+ * support the decoding of the in-progress transactions. See+ * CommandEndInvalidationMessages.
*
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
diff --git a/src/backend/utils/mmgr/mcxt.c b/src/backend/utils/mmgr/mcxt.cindex 8b6591abfb2..392602a020f 100644--- a/src/backend/utils/mmgr/mcxt.c+++ b/src/backend/utils/mmgr/mcxt.c@@ -929,7 +929,7 @@ MemoryContextCheck(MemoryContext context)
* context creation routines, not by the unwashed masses.
*
* The memory context creation procedure goes like this:
- * 1. Context-type-specific routine makes some initial space allocation,+ * 1. Context-type-specific routine makes some initial space allocation,
* including enough space for the context header. If it fails,
* it can ereport() with no damage done.
* 2. Context-type-specific routine sets up all type-specific fields of
@@ -939,7 +939,7 @@ MemoryContextCheck(MemoryContext context)
* the initial space allocation should be freed before ereport'ing.
* 3. Context-type-specific routine calls MemoryContextCreate() to fill in
* the generic header fields and link the context into the context tree.
- * 4. We return to the context-type-specific routine, which finishes+ * 4. We return to the context-type-specific routine, which finishes
* up type-specific initialization. This routine can now do things
* that might fail (like allocate more memory), so long as it's
* sure the node is left in a state that delete will handle.
--
2.25.1
[text/x-diff] 0004-doc-acronym-UTF.patch (766B, ../20230110045722.GD9837@telsasoft.com/5-0004-doc-acronym-UTF.patch)
download | inline diff:
From 6c9ab2b6afbfb40239b37d23950736d903b45ee7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sun, 25 Sep 2022 18:46:20 -0500
Subject: [PATCH 4/9] doc: acronym: UTF
for consistency
---
doc/src/sgml/charset.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgmlindex 3032392b801..1b17c1fa8c1 100644--- a/doc/src/sgml/charset.sgml+++ b/doc/src/sgml/charset.sgml@@ -2727,7 +2727,7 @@ RESET client_encoding;
<listitem>
<para>
- <acronym>UTF</acronym>-8 (8-bit UCS/Unicode Transformation+ <acronym>UTF-8</acronym> (8-bit UCS/Unicode Transformation
Format) is defined here.
</para>
</listitem>
--
2.25.1
[text/x-diff] 0005-doc-speculative-Perform-apply-of-large-transactions-.patch (915B, ../20230110045722.GD9837@telsasoft.com/6-0005-doc-speculative-Perform-apply-of-large-transactions-.patch)
download | inline diff:
From 899185d3f6f79c22e856ee3ea36e1fb089d0c6ed Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Mon, 9 Jan 2023 22:38:16 -0600
Subject: [PATCH 5/9] doc: speculative: Perform apply of large transactions by
parallel workers.
f745739697e49a38a31a755d7d36d6c97008dd9f
---
doc/src/sgml/system-views.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgmlindex 5b1c73269b9..7c8fc3f654b 100644--- a/doc/src/sgml/system-views.sgml+++ b/doc/src/sgml/system-views.sgml@@ -1580,7 +1580,7 @@
</para>
<para>
- A specualtive insertion lock consists of a transaction ID and a speculative+ A speculative insertion lock consists of a transaction ID and a speculative
insertion token. The speculative insertion token is displayed in the
<structfield>objid</structfield> column.
</para>
--
2.25.1
[text/x-diff] 0006-typos.patch (3.1K, ../20230110045722.GD9837@telsasoft.com/7-0006-typos.patch)
download | inline diff:
From f872b6ee52953522eef113a1e0801d0b05fabfbe Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Wed, 4 Jan 2023 21:51:30 -0600
Subject: [PATCH 6/9] typos
misspell-fixer and codespell
---
src/backend/access/transam/xlogrecovery.c | 2 +-
src/bin/psql/common.c | 2 +-
.../expected/test_pg_db_role_setting.out | 2 +-
.../test_pg_db_role_setting/sql/test_pg_db_role_setting.sql | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.cindex bc3c3eb3e79..5e657853066 100644--- a/src/backend/access/transam/xlogrecovery.c+++ b/src/backend/access/transam/xlogrecovery.c@@ -2114,7 +2114,7 @@ CheckRecoveryConsistency(void)
/*
* Check that pg_tblspc doesn't contain any real directories. Replay
- * of Database/CREATE_* records may have created ficticious tablespace+ * of Database/CREATE_* records may have created fictitious tablespace
* directories that should have been removed by the time consistency
* was reached.
*/
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.cindex 38f9b10b7c9..00627830c47 100644--- a/src/bin/psql/common.c+++ b/src/bin/psql/common.c@@ -1447,7 +1447,7 @@ ExecQueryAndProcessResults(const char *query,
if (!AcceptResult(result, false))
{
/*
- * Some error occured, either a server-side failure or a failure+ * Some error occurred, either a server-side failure or a failure
* to submit the command string. Record that.
*/
const char *error = PQresultErrorMessage(result);
diff --git a/src/test/modules/test_pg_db_role_setting/expected/test_pg_db_role_setting.out b/src/test/modules/test_pg_db_role_setting/expected/test_pg_db_role_setting.outindex bee237cf40b..ec18692c558 100644--- a/src/test/modules/test_pg_db_role_setting/expected/test_pg_db_role_setting.out+++ b/src/test/modules/test_pg_db_role_setting/expected/test_pg_db_role_setting.out@@ -122,7 +122,7 @@ SHOW test_pg_db_role_setting.user_param;
bbb
(1 row)
--- module is loaded, and placeholder values are succesfully set+-- module is loaded, and placeholder values are successfully set
SELECT load_test_pg_db_role_setting();
load_test_pg_db_role_setting
------------------------------
diff --git a/src/test/modules/test_pg_db_role_setting/sql/test_pg_db_role_setting.sql b/src/test/modules/test_pg_db_role_setting/sql/test_pg_db_role_setting.sqlindex c6095dfa98c..44f231c6b4b 100644--- a/src/test/modules/test_pg_db_role_setting/sql/test_pg_db_role_setting.sql+++ b/src/test/modules/test_pg_db_role_setting/sql/test_pg_db_role_setting.sql@@ -56,7 +56,7 @@ ALTER ROLE regress_regular_user SET test_pg_db_role_setting.superuser_param = 'c
SHOW test_pg_db_role_setting.superuser_param;
SHOW test_pg_db_role_setting.user_param;
--- module is loaded, and placeholder values are succesfully set+-- module is loaded, and placeholder values are successfully set
SELECT load_test_pg_db_role_setting();
SHOW test_pg_db_role_setting.superuser_param;
--
2.25.1
[text/x-diff] 0007-f-typos-from-43620e328617c1f41a2a54c8cee01723064e3ff.patch (1.2K, ../20230110045722.GD9837@telsasoft.com/8-0007-f-typos-from-43620e328617c1f41a2a54c8cee01723064e3ff.patch)
download | inline diff:
From 0b0db64fb0f9782d536a0d35c3276cd0ec769809 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Tue, 3 Jan 2023 15:05:24 -0600
Subject: [PATCH 7/9] f!typos from 43620e328617c1f41a2a54c8cee01723064e3ffa
---
src/backend/utils/mmgr/mcxt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/utils/mmgr/mcxt.c b/src/backend/utils/mmgr/mcxt.cindex 392602a020f..1c9eadeb167 100644--- a/src/backend/utils/mmgr/mcxt.c+++ b/src/backend/utils/mmgr/mcxt.c@@ -717,9 +717,9 @@ MemoryContextStatsDetail(MemoryContext context, int max_children,
* to the connected client.
*
* We don't buffer the information about all memory contexts in a
- * backend into StringInfo and log it as one message. Otherwise which- * may require the buffer to be enlarged very much and lead to OOM- * error since there can be a large number of memory contexts in a+ * backend into StringInfo and log it as one message. That would+ * require the buffer to be enlarged and could even incur an OOM+ * condition since there can be a large number of memory contexts in a
* backend. Instead, we log one message per memory context.
*/
ereport(LOG_SERVER_ONLY,
--
2.25.1
[text/x-diff] 0008-doc-review-v16-Add-USER-SET-parameter-values-for-pg_.patch (3.1K, ../20230110045722.GD9837@telsasoft.com/9-0008-doc-review-v16-Add-USER-SET-parameter-values-for-pg_.patch)
download | inline diff:
From 04c4fb3608ece1b80bbd86c6e9692da06f1c61b3 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Fri, 6 Jan 2023 11:17:49 -0600
Subject: [PATCH 8/9] doc review: v16: Add USER SET parameter values for
pg_db_role_setting
096dd80f3ccc103c8e078fca05e6ccfb2071aa91
---
doc/src/sgml/ref/alter_database.sgml | 6 +++---
doc/src/sgml/ref/alter_role.sgml | 6 +++---
doc/src/sgml/ref/psql-ref.sgml | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/ref/alter_database.sgml b/doc/src/sgml/ref/alter_database.sgmlindex 181e9d36205..0962f32e134 100644--- a/doc/src/sgml/ref/alter_database.sgml+++ b/doc/src/sgml/ref/alter_database.sgml@@ -211,9 +211,9 @@ ALTER DATABASE <replaceable class="parameter">name</replaceable> RESET ALL
<term><literal>USER SET</literal></term>
<listitem>
<para>
- Specifies that variable should be set on behalf of ordinary role.- That lets non-superuser and non-replication role to set placeholder- variables, with permission requirements is not known yet;+ Specifies that the variable should be set on behalf of an ordinary role.+ That allows non-superuser and non-replication roles to set placeholder+ variables, whose permission requirements are not known yet;
see <xref linkend="runtime-config-custom"/>. The variable won't
be set if it appears to require superuser privileges.
</para>
diff --git a/doc/src/sgml/ref/alter_role.sgml b/doc/src/sgml/ref/alter_role.sgmlindex f5c1264942f..d7c5e8debce 100644--- a/doc/src/sgml/ref/alter_role.sgml+++ b/doc/src/sgml/ref/alter_role.sgml@@ -239,9 +239,9 @@ ALTER ROLE { <replaceable class="parameter">role_specification</replaceable> | A
<term><literal>USER SET</literal></term>
<listitem>
<para>
- Specifies that variable should be set on behalf of ordinary role.- That lets non-superuser and non-replication role to set placeholder- variables, with permission requirements is not known yet;+ Specifies that the variable should be set on behalf of an ordinary role.+ That allows non-superuser and non-replication roles to set placeholder+ variables, whose permission requirements are not known yet;
see <xref linkend="runtime-config-custom"/>. The variable won't
be set if it appears to require superuser privileges.
</para>
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgmlindex 1a117dbecba..dc6528dc11d 100644--- a/doc/src/sgml/ref/psql-ref.sgml+++ b/doc/src/sgml/ref/psql-ref.sgml@@ -1901,8 +1901,8 @@ INSERT INTO tbl1 VALUES ($1, $2) \bind 'first value' 'second value' \g
</para>
<para>
- Since <productname>PostgreSQL</productname> 16 the output includes- column with the values of+ Since <productname>PostgreSQL</productname> 16, the output includes a+ column with the values of the
<link linkend="sql-alterrole-user-set"><literal>USER SET</literal></link>
flag for each setting.
</para>
--
2.25.1
[text/x-diff] 0009-remove-declared-but-undefined-functions.patch (2.2K, ../20230110045722.GD9837@telsasoft.com/10-0009-remove-declared-but-undefined-functions.patch)
download | inline diff:
From a268bc969f057c591db1e4b219d2fc30352d1a60 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Mon, 9 Jan 2023 13:21:02 -0600
Subject: [PATCH 9/9] remove declared but undefined functions
See:
b060dbe0001a1d6bf26cd294710f3cb203868d46
773df883e8f7543958d0d719c025b5f47c5a67f0
5b48925ad6ea04d1dfb5f893d1fa9dadd2a6a205
---
src/bin/pg_dump/compress_io.h | 2 --
src/include/access/gist_private.h | 2 --
src/include/access/xlogreader.h | 2 --
3 files changed, 6 deletions(-)
diff --git a/src/bin/pg_dump/compress_io.h b/src/bin/pg_dump/compress_io.hindex c04773a4006..a429dc4789d 100644--- a/src/bin/pg_dump/compress_io.h+++ b/src/bin/pg_dump/compress_io.h@@ -54,8 +54,6 @@ typedef struct cfp cfp;
extern cfp *cfopen(const char *path, const char *mode,
const pg_compress_specification compression_spec);
-extern cfp *cfdopen(int fd, const char *mode,- pg_compress_specification compression_spec);
extern cfp *cfopen_read(const char *path, const char *mode);
extern cfp *cfopen_write(const char *path, const char *mode,
const pg_compress_specification compression_spec);
diff --git a/src/include/access/gist_private.h b/src/include/access/gist_private.hindex f2bb4455f57..8af33d7b40d 100644--- a/src/include/access/gist_private.h+++ b/src/include/access/gist_private.h@@ -549,8 +549,6 @@ extern void gistSplitByKey(Relation r, Page page, IndexTuple *itup,
/* gistbuild.c */
extern IndexBuildResult *gistbuild(Relation heap, Relation index,
struct IndexInfo *indexInfo);
-extern void gistValidateBufferingOption(const char *value);-
/* gistbuildbuffers.c */
extern GISTBuildBuffers *gistInitBuildBuffers(int pagesPerBuffer, int levelStep,
int maxLevel);
diff --git a/src/include/access/xlogreader.h b/src/include/access/xlogreader.hindex da64f99f0b3..d77bb2ab9bc 100644--- a/src/include/access/xlogreader.h+++ b/src/include/access/xlogreader.h@@ -332,8 +332,6 @@ extern XLogReaderState *XLogReaderAllocate(int wal_segment_size,
const char *waldir,
XLogReaderRoutine *routine,
void *private_data);
-extern XLogReaderRoutine *LocalXLogReaderRoutine(void);-
/* Free an XLogReader */
extern void XLogReaderFree(XLogReaderState *state);
--
2.25.1
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, michael@paquier.xyz, amit.kapila16@gmail.com
Subject: Re: typos
In-Reply-To: <20230110045722.GD9837@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox