v20260316-typo-fixes.patch.txt

commit 2c2ecde0e10577b7ae3d671aa5b2331345887253
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Tue Mar 17 13:23:45 2026 +0200

    fix typos

diff --git a/src/backend/postmaster/datachecksum_state.c b/src/backend/postmaster/datachecksum_state.c
index 2384be7f657..3f3b11bb721 100644
--- a/src/backend/postmaster/datachecksum_state.c
+++ b/src/backend/postmaster/datachecksum_state.c
@@ -4,7 +4,7 @@
  *	  Background worker for enabling or disabling data checksums online as
  *	  well as functionality for manipulating data checksum state
  *
- * When enabling data checksums on a database at initdb time or when shut down
+ * When enabling data checksums on a cluster at initdb time or when shut down
  * with pg_checksums, no extra process is required as each page is checksummed,
  * and verified, when accessed.  When enabling checksums on an already running
  * cluster, this worker will ensure that all pages are checksummed before
@@ -21,7 +21,7 @@
  * "inprogress-on" which signals that write operations MUST compute and write
  * the checksum on the data page, but during reading the checksum SHALL NOT be
  * verified. This ensures that all objects created during when checksums are
- * being enabled will have checksums set, but reads wont fail due to missing or
+ * being enabled will have checksums set, but reads won't fail due to missing or
  * invalid checksums. Invalid checksums can be present in case the cluster had
  * checksums enabled, then disabled them and updated the page while they were
  * disabled.
@@ -32,7 +32,7 @@
  * the list, processing will end.  All databases MUST BE successfully processed
  * in order for data checksums to be enabled, the only exception are databases
  * which are dropped before having been processed.
-
+ *
  * Any new relation in a processed database, created during processing, will
  * see the in-progress state and will automatically be checksummed.
  *
@@ -46,13 +46,13 @@
  * 2. Disabling checksums
  * ----------------------
  * When disabling checksums, data_checksums will be set to "inprogress-off"
- * which signals that checksums are written but no longer verified. This ensure
- * that backends which have yet to move from the "on" state will still be able
- * to process data checksum validation.
+ * which signals that checksums are written but no longer need to be verified.
+ * This ensures that backends which have not yet transitioned to the
+ * "inprogress-off" state will still see valid checksums on pages.
  *
  * 3. Synchronization and Correctness
  * ----------------------------------
- * The processes involved in enabling, or disabling, data checksums in an
+ * The processes involved in enabling or disabling data checksums in an
  * online cluster must be properly synchronized with the normal backends
  * serving concurrent queries to ensure correctness. Correctness is defined
  * as the following:
@@ -74,8 +74,8 @@
  * latter with ensuring that any concurrent activity cannot break the data
  * checksum contract during processing.
  *
- * Synchronizing the state change is done with procsignal barriers, before
- * updating the controlfile with the state all other backends must absorb the
+ * Synchronizing the state change is done with procsignal barriers. Before
+ * updating the data_checksums state in the control file, all other backends must absorb the
  * barrier.  Barrier absorption will happen during interrupt processing, which
  * means that connected backends will change state at different times.  If
  * waiting for a barrier is done during startup, for example during replay, it
@@ -644,7 +644,7 @@ ProcessSingleRelationFork(Relation reln, ForkNumber forkNum, BufferAccessStrateg
 		return false;
 
 	/* Report the current relation to pgstat_activity */
-	snprintf(activity, sizeof(activity) - 1, "processing: %s.%s (%s, %dblocks)",
+	snprintf(activity, sizeof(activity) - 1, "processing: %s.%s (%s, %u blocks)",
 			 relns, RelationGetRelationName(reln), forkNames[forkNum], numblocks);
 	pgstat_report_activity(STATE_RUNNING, activity);
 	pgstat_progress_update_param(PROGRESS_DATACHECKSUMS_BLOCKS_TOTAL, numblocks);
@@ -658,7 +658,7 @@ ProcessSingleRelationFork(Relation reln, ForkNumber forkNum, BufferAccessStrateg
 	{
 		Buffer		buf = ReadBufferExtended(reln, forkNum, blknum, RBM_NORMAL, strategy);
 
-		/* Need to get an exclusive lock before we can flag as dirty */
+		/* Need to get an exclusive lock to mark the buffer as dirty */
 		LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
 
 		/*
@@ -666,7 +666,7 @@ ProcessSingleRelationFork(Relation reln, ForkNumber forkNum, BufferAccessStrateg
 		 * re-write the page to WAL even if the checksum hasn't changed,
 		 * because if there is a replica it might have a slightly different
 		 * version of the page with an invalid checksum, caused by unlogged
-		 * changes (e.g. hintbits) on the master happening while checksums
+		 * changes (e.g. hintbits) on the primary happening while checksums
 		 * were off. This can happen if there was a valid checksum on the page
 		 * at one point in the past, so only when checksums are first on, then
 		 * off, and then turned on again.  TODO: investigate if this could be