Walreceiver is a postmaster subprocess, so the startup process can't fork it
directly. Instead, it sends a signal to postmaster, asking postmaster to launch
it. Before that, however, startup process fills in WalRcvData->conninfo,
-and initializes the starting point in WalRcvData->receivedUpTo.
+and initializes the starting point in WalRcvData->receivedUpto.
As walreceiver receives WAL from the master server, and writes and flushes
-it to disk (in pg_xlog), it updates WalRcvData->receivedUpTo. Startup process
+it to disk (in pg_xlog), it updates WalRcvData->receivedUpto. Startup process
polls that to know how far it can proceed with WAL replay.
Walsender IPC
* in the primary server), and then keeps receiving XLOG records and
* writing them to the disk as long as the connection is alive. As XLOG
* records are received and flushed to disk, it updates the
- * WalRcv->receivedUpTo variable in shared memory, to inform the startup
+ * WalRcv->receivedUpto variable in shared memory, to inform the startup
* process of how far it can proceed with XLOG replay.
*
* Normal termination is by SIGTERM, which instructs the walreceiver to