From: Justin Pryzby <pryzby@telsasoft.com>
To: Erik Rijkers <er@xs4all.nl>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: fix typos
Date: Mon, 1 Aug 2022 13:11:36 -0500
Message-ID: <20220801181136.GJ15006@telsasoft.com> (raw)
In-Reply-To: <b79bfeff-d0e3-29a3-2576-0e325848dede@xs4all.nl>
References: <b79bfeff-d0e3-29a3-2576-0e325848dede@xs4all.nl>
On Mon, Aug 01, 2022 at 08:04:54PM +0200, Erik Rijkers wrote:
> Recent typos...
LGTM, thanks.
Here are some others I've been sitting on, mostly in .c files.
--
Justin
Attachments:
[text/x-diff] 0001-typos.patch (2.7K, ../20220801181136.GJ15006@telsasoft.com/2-0001-typos.patch)
download | inline diff:
From 19f320438476aff2773440447f167d06051a0a47 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Tue, 5 Jul 2022 14:12:26 -0500
Subject: [PATCH 1/4] typos
---
doc/src/sgml/brin.sgml | 2 +-
src/backend/commands/dbcommands.c | 6 +++---
src/include/replication/reorderbuffer.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgmlindex 4ee8908b65a..71697155d7c 100644--- a/doc/src/sgml/brin.sgml+++ b/doc/src/sgml/brin.sgml@@ -75,7 +75,7 @@
summarized will cause the summary information to be updated with data
from the new tuples.
When a new page is created that does not fall within the last
- summarized range, the range that the new page belongs into+ summarized range, the range that the new page belongs to
does not automatically acquire a summary tuple;
those tuples remain unsummarized until a summarization run is
invoked later, creating the initial summary for that range.
diff --git a/src/backend/commands/dbcommands.c b/src/backend/commands/dbcommands.cindex 7bc53f3a0bb..9f990a8d68f 100644--- a/src/backend/commands/dbcommands.c+++ b/src/backend/commands/dbcommands.c@@ -188,7 +188,7 @@ CreateDatabaseUsingWalLog(Oid src_dboid, Oid dst_dboid,
/*
* If the relation is from the source db's default tablespace then we
- * need to create it in the destinations db's default tablespace.+ * need to create it in the destination db's default tablespace.
* Otherwise, we need to create in the same tablespace as it is in the
* source database.
*/
@@ -1351,8 +1351,8 @@ createdb(ParseState *pstate, const CreatedbStmt *stmt)
/*
* If we're going to be reading data for the to-be-created database into
* shared_buffers, take a lock on it. Nobody should know that this
- * database exists yet, but it's good to maintain the invariant that a- * lock an AccessExclusiveLock on the database is sufficient to drop all+ * database exists yet, but it's good to maintain the invariant that an+ * AccessExclusiveLock on the database is sufficient to drop all
* of its buffers without worrying about more being read later.
*
* Note that we need to do this before entering the
diff --git a/src/include/replication/reorderbuffer.h b/src/include/replication/reorderbuffer.hindex d109d0baede..2c9206ace41 100644--- a/src/include/replication/reorderbuffer.h+++ b/src/include/replication/reorderbuffer.h@@ -262,7 +262,7 @@ typedef struct ReorderBufferTXN
* aborted. This can be a
* * plain commit record
* * plain commit record, of a parent transaction
- * * prepared tansaction+ * * prepared transaction
* * prepared transaction commit
* * plain abort record
* * prepared transaction abort
--
2.17.1
[text/x-diff] 0002-fix-whitespace.patch (1.3K, ../20220801181136.GJ15006@telsasoft.com/3-0002-fix-whitespace.patch)
download | inline diff:
From 57b1a6001b2910c9a8002e72f22391255e8b8bb9 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 23 Jul 2022 15:10:01 -0500
Subject: [PATCH 2/4] fix whitespace
weird since c91560defc57f89f7e88632ea14ae77b5cec78ee
---
src/backend/utils/cache/inval.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.cindex eb5782f82a4..c0e33c0f177 100644--- a/src/backend/utils/cache/inval.c+++ b/src/backend/utils/cache/inval.c@@ -9,8 +9,8 @@
* 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+ * 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,
--
2.17.1
[text/x-diff] 0003-f-newline.patch (710B, ../20220801181136.GJ15006@telsasoft.com/4-0003-f-newline.patch)
download | inline diff:
From 6fc057ae26567f39b85902933e4eddc9cbd9c915 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Tue, 26 Jul 2022 18:34:08 -0500
Subject: [PATCH 3/4] f!newline
---
src/backend/commands/explain.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.cindex e29c2ae206f..e078456b191 100644--- a/src/backend/commands/explain.c+++ b/src/backend/commands/explain.c@@ -3284,7 +3284,6 @@ show_hashagg_info(AggState *aggstate, ExplainState *es)
if (es->format != EXPLAIN_FORMAT_TEXT)
{
-
if (es->costs)
ExplainPropertyInteger("Planned Partitions", NULL,
aggstate->hash_planned_partitions, es);
--
2.17.1
[text/x-diff] 0004-print-oids-with-u.patch (1.5K, ../20220801181136.GJ15006@telsasoft.com/5-0004-print-oids-with-u.patch)
download | inline diff:
From 050de51a3018ed4e609a9f77385708af1692b720 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sun, 31 Jul 2022 00:30:53 -0500
Subject: [PATCH 4/4] print oids with %u
---
src/backend/replication/logical/origin.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/replication/logical/origin.c b/src/backend/replication/logical/origin.cindex c72ad6b93de..ac12f5e26cb 100644--- a/src/backend/replication/logical/origin.c+++ b/src/backend/replication/logical/origin.c@@ -364,7 +364,7 @@ restart:
if (nowait)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg("could not drop replication origin with OID %d, in use by PID %d",+ errmsg("could not drop replication origin with OID %u, in use by PID %d",
state->roident,
state->acquired_by)));
@@ -937,7 +937,7 @@ replorigin_advance(RepOriginId node,
{
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg("replication origin with OID %d is already active for PID %d",+ errmsg("replication origin with OID %u is already active for PID %d",
replication_state->roident,
replication_state->acquired_by)));
}
@@ -1126,7 +1126,7 @@ replorigin_session_setup(RepOriginId node)
{
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg("replication origin with OID %d is already active for PID %d",+ errmsg("replication origin with OID %u is already active for PID %d",
curstate->roident, curstate->acquired_by)));
}
--
2.17.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, er@xs4all.nl, pgsql-hackers@lists.postgresql.org
Subject: Re: fix typos
In-Reply-To: <20220801181136.GJ15006@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