1
0
mirror of https://github.com/postgres/postgres.git synced 2025-05-09 18:21:05 +03:00

Typo fixes. receivedUpto should be capitalized consistently.

This commit is contained in:
Robert Haas 2011-02-11 11:55:12 -05:00
parent 2c20ba1fd2
commit d309acf201
2 changed files with 3 additions and 3 deletions

View 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 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 directly. Instead, it sends a signal to postmaster, asking postmaster to launch
it. Before that, however, startup process fills in WalRcvData->conninfo, 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 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. polls that to know how far it can proceed with WAL replay.
Walsender IPC Walsender IPC

View File

@ -12,7 +12,7 @@
* in the primary server), and then keeps receiving XLOG records and * 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 * writing them to the disk as long as the connection is alive. As XLOG
* records are received and flushed to disk, it updates the * 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. * process of how far it can proceed with XLOG replay.
* *
* Normal termination is by SIGTERM, which instructs the walreceiver to * Normal termination is by SIGTERM, which instructs the walreceiver to