commit 2c2ecde0e10577b7ae3d671aa5b2331345887253 Author: Heikki Linnakangas 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