|
|
|
@ -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 |
|
|
|
|