From a59135a81aa781d126c48a516179e43dbb0d428a Mon Sep 17 00:00:00 2001 From: John Naylor Date: Tue, 15 Feb 2022 14:30:57 +0700 Subject: [PATCH] Spell "startup process" with lower case in the documentation Most uses were already lower case, so this just makes all user-visible spellings consistent. Bharath Rupireddy The proposed patch also had analagous changes for the code comments, but I decided that wasn't worth the churn. Discussion: https://www.postgresql.org/message-id/flat/CALj2ACW7%2Bv_0QBPoWB%3DqKr67JKC019Htm%3DX8sKewS17bOquefg%40mail.gmail.com --- doc/src/sgml/high-availability.sgml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 437712762a..b5b6042104 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -2127,7 +2127,7 @@ HINT: You can then restart the server after making the necessary configuration pg_cancel_backend() and pg_terminate_backend() will work on user backends, - but not the Startup process, which performs + but not the startup process, which performs recovery. pg_stat_activity does not show recovering transactions as active. As a result, pg_prepared_xacts is always empty during @@ -2139,9 +2139,9 @@ HINT: You can then restart the server after making the necessary configuration pg_locks will show locks held by backends, as normal. pg_locks also shows - a virtual transaction managed by the Startup process that owns all + a virtual transaction managed by the startup process that owns all AccessExclusiveLocks held by transactions being replayed by recovery. - Note that the Startup process does not acquire locks to + Note that the startup process does not acquire locks to make database changes, and thus locks other than AccessExclusiveLocks do not show in pg_locks for the Startup process; they are just presumed to exist. -- 2.39.5