1414 * replication-mode commands. The START_REPLICATION command begins streaming
1515 * WAL to the client. While streaming, the walsender keeps reading XLOG
1616 * records from the disk and sends them to the standby server over the
17- * COPY protocol, untilthe either side ends the replication by exiting COPY
17+ * COPY protocol, until either side ends the replication by exiting COPY
1818 * mode (or until the connection is closed).
1919 *
2020 * Normal termination is by SIGTERM, which instructs the walsender to
21- * close the connection and exit(0) at next convenient moment. Emergency
21+ * close the connection and exit(0) atthe next convenient moment. Emergency
2222 * termination is by SIGQUIT; like any backend, the walsender will simply
2323 * abort and exit on SIGQUIT. A close of the connection and a FATAL error
2424 * are treated as not a crash but approximately normal termination;
@@ -277,7 +277,7 @@ InitWalSender(void)
277277 * Clean up after an error.
278278 *
279279 * WAL sender processes don't use transactions like regular backends do.
280- * This function does any cleanuprequited after an error in a WAL sender
280+ * This function does any cleanuprequired after an error in a WAL sender
281281 * process, similar to what transaction abort does in a regular backend.
282282 */
283283void
@@ -570,7 +570,7 @@ StartReplication(StartReplicationCmd *cmd)
570570sendTimeLineIsHistoric = true;
571571
572572/*
573- * Check that the timeline the client requestedfor exists, and
573+ * Check that the timeline the client requested exists, and
574574 * the requested start location is on that timeline.
575575 */
576576timeLineHistory = readTimeLineHistory (ThisTimeLineID );
@@ -588,8 +588,8 @@ StartReplication(StartReplicationCmd *cmd)
588588 * starting point. This is because the client can legitimately
589589 * request to start replication from the beginning of the WAL
590590 * segment that contains switchpoint, but on the new timeline, so
591- * that it doesn't end up with a partial segment. If you ask for a
592- * too old starting point, you'll get an error later when we fail
591+ * that it doesn't end up with a partial segment. If you ask for
592+ * too olda starting point, you'll get an error later when we fail
593593 * to find the requested WAL segment in pg_wal.
594594 *
595595 * XXX: we could be more strict here and only allow a startpoint
@@ -626,7 +626,7 @@ StartReplication(StartReplicationCmd *cmd)
626626{
627627/*
628628 * When we first start replication the standby will be behind the
629- * primary. For some applications, for example, synchronous
629+ * primary. For some applications, for example synchronous
630630 * replication, it is important to have a clear state for this initial
631631 * catchup mode, so we can trigger actions when we change streaming
632632 * state later. We may stay in this state for a long time, which is
@@ -954,7 +954,7 @@ CreateReplicationSlot(CreateReplicationSlotCmd *cmd)
954954
955955ReplicationSlotMarkDirty ();
956956
957- /* Write this slot to disk if it's permanent one. */
957+ /* Write this slot to disk if it'sa permanent one. */
958958if (!cmd -> temporary )
959959ReplicationSlotSave ();
960960}
@@ -1111,7 +1111,7 @@ StartLogicalReplication(StartReplicationCmd *cmd)
11111111 *
11121112 * Prepare a write into a StringInfo.
11131113 *
1114- * Don't do anything lasting in here, it's quite possible that nothing will done
1114+ * Don't do anything lasting in here, it's quite possible that nothing willbe done
11151115 * with the data.
11161116 */
11171117static void
@@ -1150,7 +1150,7 @@ WalSndWriteData(LogicalDecodingContext *ctx, XLogRecPtr lsn, TransactionId xid,
11501150
11511151/*
11521152 * Fill the send timestamp last, so that it is taken as late as possible.
1153- * This is somewhat ugly, but the protocol's set as it's already used for
1153+ * This is somewhat ugly, but the protocol is set as it's already used for
11541154 * several releases by streaming physical replication.
11551155 */
11561156resetStringInfo (& tmpbuf );
@@ -1237,7 +1237,7 @@ WalSndWaitForWal(XLogRecPtr loc)
12371237
12381238
12391239/*
1240- * Fast path to avoid acquiring the spinlock inthe we already know we
1240+ * Fast path to avoid acquiring the spinlock incase we already know we
12411241 * have enough WAL available. This is particularly interesting if we're
12421242 * far behind.
12431243 */
@@ -2498,7 +2498,7 @@ XLogSendPhysical(void)
24982498 * given the current implementation of XLogRead(). And in any case
24992499 * it's unsafe to send WAL that is not securely down to disk on the
25002500 * master: if the master subsequently crashes and restarts, slaves
2501- * must not have applied any WAL thatgets lost on the master.
2501+ * must not have applied any WAL thatgot lost on the master.
25022502 */
25032503SendRqstPtr = GetFlushRecPtr ();
25042504}
@@ -2522,7 +2522,7 @@ XLogSendPhysical(void)
25222522 * LSN.
25232523 *
25242524 * Note that the LSN is not necessarily the LSN for the data contained in
2525- * the present message; it's the end of thethe WAL, which might be
2525+ * the present message; it's the end of the WAL, which might be
25262526 * further ahead. All the lag tracking machinery cares about is finding
25272527 * out when that arbitrary LSN is eventually reported as written, flushed
25282528 * and applied, so that it can measure the elapsed time.
@@ -2922,7 +2922,7 @@ WalSndShmemInit(void)
29222922 * Wake up all walsenders
29232923 *
29242924 * This will be called inside critical sections, so throwing an error is not
2925- *adviseable .
2925+ *advisable .
29262926 */
29272927void
29282928WalSndWakeup (void )
@@ -3159,7 +3159,7 @@ pg_stat_get_wal_senders(PG_FUNCTION_ARGS)
31593159}
31603160
31613161/*
3162- * This function is used to send keepalive message to standby.
3162+ * This function is used to senda keepalive message to standby.
31633163 * If requestReply is set, sets a flag in the message requesting the standby
31643164 * to send a message back to us, for heartbeat purposes.
31653165 */