@@ -4,19 +4,18 @@ Walreceiver - libpqwalreceiver API
44----------------------------------
55
66The transport-specific part of walreceiver, responsible for connecting to
7- the primary server and receiving WAL files, is loaded dynamically to avoid
8- having to link the main server binary with libpq. The dynamically loaded
9- module is in libpqwalreceiver subdirectory.
7+ the primary server, receiving WAL files and sending messages, is loaded
8+ dynamically to avoid having to link the main server binary with libpq.
9+ The dynamically loaded module is in libpqwalreceiver subdirectory.
1010
11- The dynamically loaded module implementsthree functions:
11+ The dynamically loaded module implementsfour functions:
1212
1313
1414bool walrcv_connect(char *conninfo, XLogRecPtr startpoint)
1515
1616Establish connection to the primary, and starts streaming from 'startpoint'.
1717Returns true on success.
1818
19-
2019bool walrcv_receive(int timeout, unsigned char *type, char **buffer, int *len)
2120
2221Retrieve any message available through the connection, blocking for
@@ -26,6 +25,10 @@ otherwise false. On success, a pointer to the message payload is stored in
2625returned buffer is valid until the next call to walrcv_* functions, the
2726caller should not attempt freeing it.
2827
28+ void walrcv_send(const char *buffer, int nbytes)
29+
30+ Send a message to XLOG stream.
31+
2932void walrcv_disconnect(void);
3033
3134Disconnect.
@@ -45,11 +48,15 @@ to fetch more WAL (if streaming replication is configured).
4548Walreceiver is a postmaster subprocess, so the startup process can't fork it
4649directly. Instead, it sends a signal to postmaster, asking postmaster to launch
4750it. Before that, however, startup process fills in WalRcvData->conninfo,
48- and initializes the starting point in WalRcvData->receivedUpto .
51+ and initializes the starting point in WalRcvData->receiveStart .
4952
5053As walreceiver receives WAL from the master server, and writes and flushes
51- it to disk (in pg_xlog), it updates WalRcvData->receivedUpto. Startup process
52- polls that to know how far it can proceed with WAL replay.
54+ it to disk (in pg_xlog), it updates WalRcvData->receivedUpto and signals
55+ the startup process to know how far WAL replay can advance.
56+
57+ Walreceiver sends information about replication progress to the master server
58+ whenever either it writes or flushes new WAL, or the specified interval elapses.
59+ This is used for reporting purpose.
5360
5461Walsender IPC
5562-------------
@@ -80,11 +87,9 @@ phase. A walsenders will look like a regular backends until it's done with the
8087initialization and has marked itself in PMSignal array, and at process
8188termination, after unmarking the PMSignal slot.
8289
83- Each walsender allocates an entry from the WalSndCtl array, and advertises
84- there how far it has streamed WAL already. This is used at checkpoints, to
85- avoid recycling WAL that hasn't been streamed to a slave yet. However,
86- that doesn't stop such WAL from being recycled when the connection is not
87- established.
90+ Each walsender allocates an entry from the WalSndCtl array, and tracks
91+ information about replication progress. User can monitor them via
92+ statistics views.
8893
8994
9095Walsender - walreceiver protocol