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
>From 8b56d6007e13e3b42bc75da3b9174ecab8a8dd70 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@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.yml
index 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
>From c082768a857ebd7a0a534ee497761dca0c621f64 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@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.c
index 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/README
index 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.c
index 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.c
index 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.c
index 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.c
index 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.h
index 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
>From 6a80a46886d3659a3ccd5783fdf16b2ae750d73b Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@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_vsc2dxqz...@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.c
index 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.c
index 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
>From 6c9ab2b6afbfb40239b37d23950736d903b45ee7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@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.sgml
index 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
>From 899185d3f6f79c22e856ee3ea36e1fb089d0c6ed Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@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.sgml
index 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
>From f872b6ee52953522eef113a1e0801d0b05fabfbe Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@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.c
index 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.c
index 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.out
index 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.sql
index 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
>From 0b0db64fb0f9782d536a0d35c3276cd0ec769809 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@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.c
index 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
>From 04c4fb3608ece1b80bbd86c6e9692da06f1c61b3 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@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.sgml
index 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.sgml
index 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.sgml
index 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
>From a268bc969f057c591db1e4b219d2fc30352d1a60 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@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.h
index 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.h
index 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.h
index 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
