From d309acf201ab2c5bbd1f6a5d51e4a8060eb6a63c Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Fri, 11 Feb 2011 11:55:12 -0500 Subject: [PATCH] Typo fixes. receivedUpto should be capitalized consistently. --- src/backend/replication/README | 4 ++-- src/backend/replication/walreceiver.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/backend/replication/README b/src/backend/replication/README index 9c2e0d8e97..744ddc7fe8 100644 --- a/src/backend/replication/README +++ b/src/backend/replication/README @@ -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 diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index 30e35dbd28..3277da8fc3 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -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