Обсуждение: Unhyphenation of crash-recovery
Hello, this is a derived topic from [1], summarized as $SUBJECT. This just removes useless hyphens from the words "(crash|emergency)-recovery". We don't have such wordings for "archive recovery" This patch fixes non-user-facing texts as well as user-facing ones. regards. [1] https://www.postgresql.org/message-id/20220316.091913.806120467943749797.horikyota.ntt%40gmail.com -- Kyotaro Horiguchi NTT Open Source Software Center From 751acd2510e036a5c484e5768dd9e4e85cd8b2cf Mon Sep 17 00:00:00 2001 From: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Date: Fri, 4 Mar 2022 13:53:38 +0900 Subject: [PATCH v13] Get rid of uses of some hyphenated words There are use of both "crash-recovery" and "crash recovery" in the tree. All occurances of archive recovery is spelled unhyphenated. Unify the similar uses to unhyphenated. --- doc/src/sgml/ref/pg_ctl-ref.sgml | 2 +- doc/src/sgml/ref/postgres-ref.sgml | 2 +- src/backend/commands/trigger.c | 2 +- src/backend/utils/cache/relcache.c | 2 +- src/test/recovery/t/023_pitr_prepared_xact.pl | 2 +- src/test/regress/parallel_schedule | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/src/sgml/ref/pg_ctl-ref.sgml b/doc/src/sgml/ref/pg_ctl-ref.sgml index 3946fa52ea..7cbe5c3048 100644 --- a/doc/src/sgml/ref/pg_ctl-ref.sgml +++ b/doc/src/sgml/ref/pg_ctl-ref.sgml @@ -194,7 +194,7 @@ PostgreSQL documentation rolled back and clients are forcibly disconnected, then the server is shut down. <quote>Immediate</quote> mode will abort all server processes immediately, without a clean shutdown. This choice - will lead to a crash-recovery cycle during the next server start. + will lead to a crash recovery cycle during the next server start. </para> <para> diff --git a/doc/src/sgml/ref/postgres-ref.sgml b/doc/src/sgml/ref/postgres-ref.sgml index 55a3f6c69d..fc22fbc4fe 100644 --- a/doc/src/sgml/ref/postgres-ref.sgml +++ b/doc/src/sgml/ref/postgres-ref.sgml @@ -719,7 +719,7 @@ PostgreSQL documentation is also unwise to send <literal>SIGKILL</literal> to a server process — the main <command>postgres</command> process will interpret this as a crash and will force all the sibling processes - to quit as part of its standard crash-recovery procedure. + to quit as part of its standard crash recovery procedure. </para> </refsect1> diff --git a/src/backend/commands/trigger.c b/src/backend/commands/trigger.c index e08bd9a370..ce170b4c6e 100644 --- a/src/backend/commands/trigger.c +++ b/src/backend/commands/trigger.c @@ -1887,7 +1887,7 @@ RelationBuildTriggers(Relation relation) /* * Note: since we scan the triggers using TriggerRelidNameIndexId, we will * be reading the triggers in name order, except possibly during - * emergency-recovery operations (ie, IgnoreSystemIndexes). This in turn + * emergency recovery operations (ie, IgnoreSystemIndexes). This in turn * ensures that triggers will be fired in name order. */ ScanKeyInit(&skey, diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c index fccffce572..2419cf5285 100644 --- a/src/backend/utils/cache/relcache.c +++ b/src/backend/utils/cache/relcache.c @@ -6598,7 +6598,7 @@ RelationCacheInitFilePostInvalidate(void) * Remove the init files during postmaster startup. * * We used to keep the init files across restarts, but that is unsafe in PITR - * scenarios, and even in simple crash-recovery cases there are windows for + * scenarios, and even in simple crash recovery cases there are windows for * the init files to become out-of-sync with the database. So now we just * remove them during startup and expect the first backend launch to rebuild * them. Of course, this has to happen in each database of the cluster. diff --git a/src/test/recovery/t/023_pitr_prepared_xact.pl b/src/test/recovery/t/023_pitr_prepared_xact.pl index 39e8a8fa17..0f48c20ed1 100644 --- a/src/test/recovery/t/023_pitr_prepared_xact.pl +++ b/src/test/recovery/t/023_pitr_prepared_xact.pl @@ -1,7 +1,7 @@ # Copyright (c) 2021-2022, PostgreSQL Global Development Group -# Test for point-in-time-recovery (PITR) with prepared transactions +# Test for point-in-time recovery (PITR) with prepared transactions use strict; use warnings; use PostgreSQL::Test::Cluster; diff --git a/src/test/regress/parallel_schedule b/src/test/regress/parallel_schedule index 6d8f524ae9..8251744bbf 100644 --- a/src/test/regress/parallel_schedule +++ b/src/test/regress/parallel_schedule @@ -13,7 +13,7 @@ test: test_setup # run tablespace by itself, and early, because it forces a checkpoint; # we'd prefer not to have checkpoints later in the tests because that -# interferes with crash-recovery testing. +# interferes with crash recovery testing. test: tablespace # ---------- -- 2.27.0
Hi On March 15, 2022 6:25:09 PM PDT, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: >Hello, this is a derived topic from [1], summarized as $SUBJECT. > >This just removes useless hyphens from the words >"(crash|emergency)-recovery". We don't have such wordings for "archive >recovery" This patch fixes non-user-facing texts as well as >user-facing ones. I don't see the point of this kind of change. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Tue, Mar 15, 2022 at 9:39 PM Andres Freund <andres@anarazel.de> wrote: > On March 15, 2022 6:25:09 PM PDT, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > >Hello, this is a derived topic from [1], summarized as $SUBJECT. > > > >This just removes useless hyphens from the words > >"(crash|emergency)-recovery". We don't have such wordings for "archive > >recovery" This patch fixes non-user-facing texts as well as > >user-facing ones. > > I don't see the point of this kind of change. It seems like better grammar to me, although whether it is worth the effort to go fix everything of this kind is certainly debatable. -- Robert Haas EDB: http://www.enterprisedb.com
On 16.03.22 02:25, Kyotaro Horiguchi wrote:
> Hello, this is a derived topic from [1], summarized as $SUBJECT.
>
> This just removes useless hyphens from the words
> "(crash|emergency)-recovery". We don't have such wordings for "archive
> recovery" This patch fixes non-user-facing texts as well as
> user-facing ones.
Most changes in this patch are not the correct direction. The hyphens
are used to group compound adjectives before nouns. For example,
simple crash-recovery cases
means
simple (crash recovery) cases
rather than
simple crash (recovery cases)
if it were without hyphens.
At Thu, 17 Mar 2022 07:42:42 +0100, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote in > On 16.03.22 02:25, Kyotaro Horiguchi wrote: > > Hello, this is a derived topic from [1], summarized as $SUBJECT. > > This just removes useless hyphens from the words > > "(crash|emergency)-recovery". We don't have such wordings for "archive > > recovery" This patch fixes non-user-facing texts as well as > > user-facing ones. > > Most changes in this patch are not the correct direction. The hyphens > are used to group compound adjectives before nouns. For example, > > simple crash-recovery cases > > means > > simple (crash recovery) cases > > rather than > > simple crash (recovery cases) > > if it were without hyphens. Really? The latter recognization doesn't seem to make sense. I might be too-trained so that I capture "(crash|archive|blah) recovery" as implicit compound words. But anyway there's no strong reason to be aggressive to unhyphenate compound words. "point-in-time-recovery" and "(during) emergency-recovery operations" seem like better be unhyphnated, but now I'm not sure it is really so. Thanks for the comments. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
On Thu, Mar 17, 2022 at 2:42 AM Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > On 16.03.22 02:25, Kyotaro Horiguchi wrote: > > Hello, this is a derived topic from [1], summarized as $SUBJECT. > > > > This just removes useless hyphens from the words > > "(crash|emergency)-recovery". We don't have such wordings for "archive > > recovery" This patch fixes non-user-facing texts as well as > > user-facing ones. > > Most changes in this patch are not the correct direction. The hyphens > are used to group compound adjectives before nouns. For example, > > simple crash-recovery cases > > means > > simple (crash recovery) cases > > rather than > > simple crash (recovery cases) > > if it were without hyphens. I agree with that as a general principle, but I also think the particular case you've chosen here is a good example of another principle: sometimes it just doesn't matter very much. A case of crash recovery that happens to be simple is pretty much the same thing as a case of recovery that is simple and involves a crash. My understanding of English grammar is that one typically does not hyphenate unless it is required to avoid confusion. A quick Google search suggests this example: Mr Harper had a funny smelling dog We must try to figure out whether the smell of the dog is funny or whether the dog itself is both funny and smelling. If we hyphenate funny-smelling, then it's clear that it is the smell of the dog that is funny and not the dog itself. But in your example I cannot see that there is any similar ambiguity. Recovery cases can involve a crash, and crash recovery can have cases, and what's the difference, anyway? So I wouldn't hyphenate it, but I also wouldn't spend a lot of time arguing if someone else did. Except maybe that's exactly what I am doing. Perhaps I should find something else to do. -- Robert Haas EDB: http://www.enterprisedb.com