fix typos
Recent typos...
Attachments:
drop_extension.sgml.diff.20220801.txttext/plain; charset=UTF-8; name=drop_extension.sgml.diff.20220801.txtDownload
--- ./doc/src/sgml/ref/drop_extension.sgml.orig 2022-08-01 19:38:18.249729884 +0200
+++ ./doc/src/sgml/ref/drop_extension.sgml 2022-08-01 19:40:33.312359069 +0200
@@ -32,7 +32,7 @@
<command>DROP EXTENSION</command> removes extensions from the database.
Dropping an extension causes its component objects, and other explicitly
dependent routines (see <xref linkend="sql-alterroutine"/>,
- the depends on extension action), to be dropped as well.
+ that depend on extension action), to be dropped as well.
</para>
<para>
@@ -80,8 +80,8 @@
<listitem>
<para>
This option prevents the specified extensions from being dropped
- if there exists non-extension-member objects that depends on any
- the extensions. This is the default.
+ if there exist non-extension-member objects that depend on any
+ of the extensions. This is the default.
</para>
</listitem>
</varlistentry>
psql-ref.sgml.diff.20220801.txttext/plain; charset=UTF-8; name=psql-ref.sgml.diff.20220801.txtDownload
--- ./doc/src/sgml/ref/psql-ref.sgml.orig 2022-08-01 19:58:21.000644788 +0200
+++ ./doc/src/sgml/ref/psql-ref.sgml 2022-08-01 19:59:00.417285655 +0200
@@ -2864,7 +2864,7 @@
</para>
<para>
- <literal>page</literal>: truncate the the header line at the terminal
+ <literal>page</literal>: truncate the header line at the terminal
width.
</para>
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:
0001-typos.patchtext/x-diff; charset=us-asciiDownload
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.sgml
index 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.c
index 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.h
index 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
0002-fix-whitespace.patchtext/x-diff; charset=us-asciiDownload
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.c
index 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
0003-f-newline.patchtext/x-diff; charset=us-asciiDownload
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.c
index 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
0004-print-oids-with-u.patchtext/x-diff; charset=us-asciiDownload
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.c
index 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
On Tue, Aug 2, 2022 at 1:05 AM Erik Rijkers <er@xs4all.nl> wrote:
Recent typos...
The part of the sentence inside parentheses is not clear to me, before or
after the patch:
Dropping an extension causes its component objects, and other explicitly
dependent routines (see <xref linkend="sql-alterroutine"/>,
- the depends on extension action), to be dropped as well.
+ that depend on extension action), to be dropped as well.
</para>--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
Here are some others I've been sitting on, mostly in .c files.
0002:
weird since c91560defc57f89f7e88632ea14ae77b5cec78ee
It was weird long before that, maybe we should instead change most of those
tabs in the top comment to single space, as is customary? The rest LGTM.
--
John Naylor
EDB: http://www.enterprisedb.com
Op 02-08-2022 om 07:28 schreef John Naylor:
On Tue, Aug 2, 2022 at 1:05 AM Erik Rijkers <er@xs4all.nl
<mailto:er@xs4all.nl>> wrote:Recent typos...
The part of the sentence inside parentheses is not clear to me, before
or after the patch:Dropping an extension causes its component objects, and other explicitly dependent routines (see <xref linkend="sql-alterroutine"/>, - the depends on extension action), to be dropped as well. + that depend on extension action), to be dropped as well. </para>
Hm, I see what you mean, I did not notice that earlier and I won't make
a guess as to intention. Maybe Bruce can have another look? (commit
5fe2d4c56e)
Show quoted text
--
John Naylor
EDB: http://www.enterprisedb.com <http://www.enterprisedb.com>
On Tue, Aug 2, 2022 at 4:32 AM Erik Rijkers <er@xs4all.nl> wrote:
The part of the sentence inside parentheses is not clear to me, before
or after the patch:Dropping an extension causes its component objects, and other explicitly dependent routines (see <xref linkend="sql-alterroutine"/>, - the depends on extension action), to be dropped as well. + that depend on extension action), to be dropped as well. </para>Hm, I see what you mean, I did not notice that earlier and I won't make
a guess as to intention. Maybe Bruce can have another look? (commit
5fe2d4c56e)
I think that it's talking about this (documented) syntax:
ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
[ NO ] DEPENDS ON EXTENSION extension_name
So the change from "depends" to "depend" here is incorrect. Maybe we
can say something like:
the <literal>DEPENDS ON EXTENSION
<replaceable>extension_name</replaceable><literal> action
(I haven't tested whether this markup works.)
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Aug 3, 2022 at 11:41 PM Robert Haas <robertmhaas@gmail.com> wrote:
I think that it's talking about this (documented) syntax:
ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
[ NO ] DEPENDS ON EXTENSION extension_nameSo the change from "depends" to "depend" here is incorrect. Maybe we
can say something like:the <literal>DEPENDS ON EXTENSION
<replaceable>extension_name</replaceable><literal> action(I haven't tested whether this markup works.)
Makes sense, I'll go make it happen.
--
John Naylor
EDB: http://www.enterprisedb.com
On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
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.
I pushed Robert's suggestion, then pushed the rest of Erik's changes and
two of Justin's. For Justin's 0004:
--- 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",RepOriginId is a typedef for uint16, so this can't print the wrong answer,
but it is inconsistent with other uses. So it seems we don't need to
backpatch this one?
For patch 0002, the whitespace issue in the top comment in inval.c, I'm
inclined to just change all the out-of-place tabs in a single commit, so we
can add that to the list of whitespace commits.
--
John Naylor
EDB: http://www.enterprisedb.com
John Naylor <john.naylor@enterprisedb.com> writes:
On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote: 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",
RepOriginId is a typedef for uint16, so this can't print the wrong answer,
but it is inconsistent with other uses. So it seems we don't need to
backpatch this one?
Um ... if it's int16, then it can't be an OID, so I'd say this message has
far worse problems than %d vs %u. It should not use that terminology.
regards, tom lane
On Thu, Aug 4, 2022 at 8:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
John Naylor <john.naylor@enterprisedb.com> writes:
RepOriginId is a typedef for uint16, so this can't print the wrong
answer,
but it is inconsistent with other uses. So it seems we don't need to
backpatch this one?Um ... if it's int16, then it can't be an OID, so I'd say this message has
far worse problems than %d vs %u. It should not use that terminology.
The catalog has the following. Since it's not a real oid, maybe this column
should be rethought?
CATALOG(pg_replication_origin,6000,ReplicationOriginRelationId)
BKI_SHARED_RELATION
{
/*
* Locally known id that get included into WAL.
*
* This should never leave the system.
*
* Needs to fit into an uint16, so we don't waste too much space in WAL
* records. For this reason we don't use a normal Oid column here, since
* we need to handle allocation of new values manually.
*/
Oid roident;
[...]
--
John Naylor
EDB: http://www.enterprisedb.com
I wrote:
On Thu, Aug 4, 2022 at 8:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
John Naylor <john.naylor@enterprisedb.com> writes:
RepOriginId is a typedef for uint16, so this can't print the wrong answer,
but it is inconsistent with other uses. So it seems we don't need to
backpatch this one?Um ... if it's int16, then it can't be an OID, so I'd say this message has
far worse problems than %d vs %u. It should not use that terminology.The catalog has the following. Since it's not a real oid, maybe this column should be rethought?
This is really a straw-man proposal, since I'm not volunteering to do
the work, or suggest anybody else should do the same. That being the
case, it seems we should just go ahead with Justin's patch for
consistency. Possibly we could also change the messages to say "ID"?
CATALOG(pg_replication_origin,6000,ReplicationOriginRelationId) BKI_SHARED_RELATION
{
/*
* Locally known id that get included into WAL.
*
* This should never leave the system.
*
* Needs to fit into an uint16, so we don't waste too much space in WAL
* records. For this reason we don't use a normal Oid column here, since
* we need to handle allocation of new values manually.
*/
Oid roident;
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Aug 12, 2022, at 3:59 AM, John Naylor wrote:
This is really a straw-man proposal, since I'm not volunteering to do
the work, or suggest anybody else should do the same. That being the
case, it seems we should just go ahead with Justin's patch for
consistency. Possibly we could also change the messages to say "ID"?
... or say
could not drop replication origin %u, in use by PID %d
AFAICS there is no "with ID" but there is "with identifier". I personally
prefer to omit these additional words; it seems clear without them.
--
Euler Taveira
EDB https://www.enterprisedb.com/
John Naylor <john.naylor@enterprisedb.com> writes:
This is really a straw-man proposal, since I'm not volunteering to do
the work, or suggest anybody else should do the same. That being the
case, it seems we should just go ahead with Justin's patch for
consistency. Possibly we could also change the messages to say "ID"?
I'd be content if we change the user-facing messages (and documentation
if any) to say "ID" not "OID".
regards, tom lane
On Fri, Aug 12, 2022 at 8:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
John Naylor <john.naylor@enterprisedb.com> writes:
This is really a straw-man proposal, since I'm not volunteering to do
the work, or suggest anybody else should do the same. That being the
case, it seems we should just go ahead with Justin's patch for
consistency. Possibly we could also change the messages to say "ID"?I'd be content if we change the user-facing messages (and documentation
if any) to say "ID" not "OID".
The documentation has both, so it makes sense to standardize on "ID".
The messages all had oid/OID, which I changed in the attached. I think
I got all the places.
I'm thinking it's not wrong enough to confuse people, but consistency
is good, so backpatch to v15 and no further. Does anyone want to make
a case otherwise?
--
John Naylor
EDB: http://www.enterprisedb.com
Attachments:
v1-consistently-refer-to-roident-as-ID-in-messages-and-docs.patchtext/x-patch; charset=US-ASCII; name=v1-consistently-refer-to-roident-as-ID-in-messages-and-docs.patchDownload
diff --git a/doc/src/sgml/replication-origins.sgml b/doc/src/sgml/replication-origins.sgml
index 7e02c4605b..bb0fb624d2 100644
--- a/doc/src/sgml/replication-origins.sgml
+++ b/doc/src/sgml/replication-origins.sgml
@@ -27,12 +27,12 @@
</para>
<para>
- Replication origins have just two properties, a name and an OID. The name,
+ Replication origins have just two properties, a name and an ID. The name,
which is what should be used to refer to the origin across systems, is
free-form <type>text</type>. It should be used in a way that makes conflicts
between replication origins created by different replication solutions
unlikely; e.g., by prefixing the replication solution's name to it.
- The OID is used only to avoid having to store the long version
+ The ID is used only to avoid having to store the long version
in situations where space efficiency is important. It should never be shared
across systems.
</para>
diff --git a/src/backend/replication/logical/origin.c b/src/backend/replication/logical/origin.c
index c72ad6b93d..9eb97fac58 100644
--- a/src/backend/replication/logical/origin.c
+++ b/src/backend/replication/logical/origin.c
@@ -328,7 +328,7 @@ replorigin_create(const char *roname)
if (tuple == NULL)
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
- errmsg("could not find free replication origin OID")));
+ errmsg("could not find free replication origin ID")));
heap_freetuple(tuple);
return roident;
@@ -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 ID %u, in use by PID %d",
state->roident,
state->acquired_by)));
@@ -408,7 +408,7 @@ restart:
*/
tuple = SearchSysCache1(REPLORIGIDENT, ObjectIdGetDatum(roident));
if (!HeapTupleIsValid(tuple))
- elog(ERROR, "cache lookup failed for replication origin with oid %u",
+ elog(ERROR, "cache lookup failed for replication origin with ID %u",
roident);
CatalogTupleDelete(rel, &tuple->t_self);
@@ -485,7 +485,7 @@ replorigin_by_oid(RepOriginId roident, bool missing_ok, char **roname)
if (!missing_ok)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
- errmsg("replication origin with OID %u does not exist",
+ errmsg("replication origin with ID %u does not exist",
roident)));
return false;
@@ -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 ID %u is already active for PID %d",
replication_state->roident,
replication_state->acquired_by)));
}
@@ -948,7 +948,7 @@ replorigin_advance(RepOriginId node,
if (replication_state == NULL && free_state == NULL)
ereport(ERROR,
(errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
- errmsg("could not find free replication state slot for replication origin with OID %u",
+ errmsg("could not find free replication state slot for replication origin with ID %u",
node),
errhint("Increase max_replication_slots and try again.")));
@@ -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 ID %u is already active for PID %d",
curstate->roident, curstate->acquired_by)));
}
@@ -1138,7 +1138,7 @@ replorigin_session_setup(RepOriginId node)
if (session_replication_state == NULL && free_slot == -1)
ereport(ERROR,
(errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
- errmsg("could not find free replication state slot for replication origin with OID %u",
+ errmsg("could not find free replication state slot for replication origin with ID %u",
node),
errhint("Increase max_replication_slots and try again.")));
else if (session_replication_state == NULL)
On Tue, Aug 16, 2022 at 8:48 AM John Naylor
<john.naylor@enterprisedb.com> wrote:
On Fri, Aug 12, 2022 at 8:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
John Naylor <john.naylor@enterprisedb.com> writes:
This is really a straw-man proposal, since I'm not volunteering to do
the work, or suggest anybody else should do the same. That being the
case, it seems we should just go ahead with Justin's patch for
consistency. Possibly we could also change the messages to say "ID"?I'd be content if we change the user-facing messages (and documentation
if any) to say "ID" not "OID".The documentation has both, so it makes sense to standardize on "ID".
The messages all had oid/OID, which I changed in the attached. I think
I got all the places.I'm thinking it's not wrong enough to confuse people, but consistency
is good, so backpatch to v15 and no further. Does anyone want to make
a case otherwise?
This is done.
--
John Naylor
EDB: http://www.enterprisedb.com