ensure, not insure
Hi,
While looking at GUC messages today I noticed the following:
gettext_noop("The server will use the fsync() system call in several
places to make "
"sure that updates are physically written to disk. This insures "
"that a database cluster will recover to a consistent state after "
"an operating system or hardware crash.")
~
I believe the word should have been "ensures"; not "insures".
In passing I found/fixed a bunch of similar misuses in comments.
======
Kind Regards,
Peter Smith.
Fujitsu Australia.
Attachments:
v1-0001-ensure-not-insure.patchapplication/octet-stream; name=v1-0001-ensure-not-insure.patchDownload
From c5347824e5b0d8ff50f63b52aed5e092ffa87e47 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.b.smith@fujitsu.com>
Date: Wed, 8 Nov 2023 17:45:22 +1100
Subject: [PATCH v1] ensure not insure
---
src/backend/access/heap/hio.c | 2 +-
src/backend/utils/misc/guc_tables.c | 2 +-
src/include/storage/buf_internals.h | 2 +-
src/tools/pg_bsd_indent/indent.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c
index caa6270..ccc4c69 100644
--- a/src/backend/access/heap/hio.c
+++ b/src/backend/access/heap/hio.c
@@ -563,7 +563,7 @@ RelationGetBufferForTuple(Relation relation, Size len,
* on, as cached in the BulkInsertState or relcache entry. If that
* doesn't work, we ask the Free Space Map to locate a suitable page.
* Since the FSM's info might be out of date, we have to be prepared to
- * loop around and retry multiple times. (To insure this isn't an infinite
+ * loop around and retry multiple times. (To ensure this isn't an infinite
* loop, we must update the FSM with the correct amount of free space on
* each page that proves not to be suitable.) If the FSM has no record of
* a page with enough free space, we give up and extend the relation.
diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c
index 7605eff..beed72a 100644
--- a/src/backend/utils/misc/guc_tables.c
+++ b/src/backend/utils/misc/guc_tables.c
@@ -1111,7 +1111,7 @@ struct config_bool ConfigureNamesBool[] =
{"fsync", PGC_SIGHUP, WAL_SETTINGS,
gettext_noop("Forces synchronization of updates to disk."),
gettext_noop("The server will use the fsync() system call in several places to make "
- "sure that updates are physically written to disk. This insures "
+ "sure that updates are physically written to disk. This ensures "
"that a database cluster will recover to a consistent state after "
"an operating system or hardware crash.")
},
diff --git a/src/include/storage/buf_internals.h b/src/include/storage/buf_internals.h
index bc79a32..98cd249 100644
--- a/src/include/storage/buf_internals.h
+++ b/src/include/storage/buf_internals.h
@@ -212,7 +212,7 @@ BufMappingPartitionLockByIndex(uint32 index)
* is held. Thus buffer header lock holder can do complex updates of the
* state variable in single write, simultaneously with lock release (cleaning
* BM_LOCKED flag). On the other hand, updating of state without holding
- * buffer header lock is restricted to CAS, which insure that BM_LOCKED flag
+ * buffer header lock is restricted to CAS, which ensures that BM_LOCKED flag
* is not set. Atomic increment/decrement, OR/AND etc. are not allowed.
*
* An exception is that if we have the buffer pinned, its tag can't change
diff --git a/src/tools/pg_bsd_indent/indent.c b/src/tools/pg_bsd_indent/indent.c
index 2fd8771..923fc34 100644
--- a/src/tools/pg_bsd_indent/indent.c
+++ b/src/tools/pg_bsd_indent/indent.c
@@ -608,7 +608,7 @@ check_type:
parse(hd_type); /* let parser worry about if, or whatever */
}
- ps.search_brace = btype_2; /* this should insure that constructs
+ ps.search_brace = btype_2; /* this should ensure that constructs
* such as main(){...} and int[]{...}
* have their braces put in the right
* place */
--
1.8.3.1
On Wed, 8 Nov 2023 at 19:56, Peter Smith <smithpb2250@gmail.com> wrote:
gettext_noop("The server will use the fsync() system call in several
places to make "
"sure that updates are physically written to disk. This insures "
"that a database cluster will recover to a consistent state after "
"an operating system or hardware crash.")~
I believe the word should have been "ensures"; not "insures".
I agree. It's surprisingly ancient, having arrived in b700a672f (June 2003).
In passing I found/fixed a bunch of similar misuses in comments.
Those all look fine to me too.
David
On Wed, Nov 08, 2023 at 08:31:28PM +1300, David Rowley wrote:
On Wed, 8 Nov 2023 at 19:56, Peter Smith <smithpb2250@gmail.com> wrote:
In passing I found/fixed a bunch of similar misuses in comments.
Those all look fine to me too.
+1.
--
Michael
On Thu, 9 Nov 2023 at 14:22, Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Nov 08, 2023 at 08:31:28PM +1300, David Rowley wrote:
Those all look fine to me too.
+1.
I've pushed this. I backpatched due to the typo in the fsync GUC
description. I'd have only pushed to master if it were just the
comment typos.
I noticed older versions had another instance of "insure" in a code
comment. I opted to leave that one alone since that file is now gone
in more recent versions.
David
David Rowley <dgrowleyml@gmail.com> writes:
I've pushed this. I backpatched due to the typo in the fsync GUC
description. I'd have only pushed to master if it were just the
comment typos.
FTR, I do not think you should have back-patched. You created extra
work for the translation team, and the mistake is subtle enough that
it wasn't worth that. (My dictionary says that "insure and ensure
are often interchangeable, particularly in US English".)
regards, tom lane