Typo fixes. receivedUpto should be capitalized consistently.
authorRobert Haas <[email protected]>
Fri, 11 Feb 2011 16:55:12 +0000 (11:55 -0500)
committerRobert Haas <[email protected]>
Fri, 11 Feb 2011 16:55:12 +0000 (11:55 -0500)
src/backend/replication/README
src/backend/replication/walreceiver.c

index 9c2e0d8e974a6219fc3b1be65927b264d1460a53..744ddc7fe8f70e689f5002ede3ffc7bdcb2070e3 100644 (file)
@@ -45,10 +45,10 @@ to fetch more WAL (if streaming replication is configured).
 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
index 30e35dbd28ad976f05e8a259961ecb4fd8a3cd4e..3277da8fc33029aeff1f5c775f0ea747775b7231 100644 (file)
@@ -12,7 +12,7 @@
  * 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