33 * walsender.c
44 *
55 * The WAL sender process (walsender) is new as of Postgres 9.0. It takes
6- * charge of XLOG streaming sender in the primary server. At first, it is
7- * started by the postmaster when the walreceiver in the standby server
6+ * care of sending XLOG from the primary server to a single recipient.
7+ * (Note that there can be more than one walsender process concurrently.)
8+ * It is started by the postmaster when the walreceiver of a standby server
89 * connects to the primary server and requests XLOG streaming replication.
910 * It attempts to keep reading XLOG records from the disk and sending them
1011 * to the standby server, as long as the connection is alive (i.e., like
2324 * This instruct walsender to send any outstanding WAL, including the
2425 * shutdown checkpoint record, and then exit.
2526 *
26- * Note that there can be more than one walsender process concurrently.
2727 *
2828 * Portions Copyright (c) 2010-2010, PostgreSQL Global Development Group
2929 *
30- *
3130 * IDENTIFICATION
32- * $PostgreSQL: pgsql/src/backend/replication/walsender.c,v 1.26 2010/06/03 23:00:14 tgl Exp $
31+ * $PostgreSQL: pgsql/src/backend/replication/walsender.c,v 1.27 2010/06/17 16:41:25 tgl Exp $
3332 *
3433 *-------------------------------------------------------------------------
3534 */
@@ -641,7 +640,7 @@ XLogRead(char *buf, XLogRecPtr recptr, Size nbytes)
641640}
642641
643642/*
644- * Read up to MAX_SEND_SIZE bytes of WAL that's beenwritten to disk,
643+ * Read up to MAX_SEND_SIZE bytes of WAL that's beenflushed to disk,
645644 * but not yet sent to the client, and send it.
646645 *
647646 * msgbuf is a work area in which the output message is constructed. It's
@@ -663,11 +662,14 @@ XLogSend(char *msgbuf, bool *caughtup)
663662WalDataMessageHeader msghdr ;
664663
665664/*
666- * Attempt to send all data that's already been written out from WAL
667- * buffers (note it might not yet be fsync'd to disk). We cannot go
668- * further than that given the current implementation of XLogRead().
665+ * Attempt to send all data that's already been written out and fsync'd
666+ * to disk. We cannot go further than what's been written out given the
667+ * current implementation of XLogRead(). And in any case it's unsafe to
668+ * send WAL that is not securely down to disk on the master: if the master
669+ * subsequently crashes and restarts, slaves must not have applied any WAL
670+ * that gets lost on the master.
669671 */
670- SendRqstPtr = GetWriteRecPtr ();
672+ SendRqstPtr = GetFlushRecPtr ();
671673
672674/* Quick exit if nothing to do */
673675if (XLByteLE (SendRqstPtr ,sentPtr ))
@@ -679,7 +681,7 @@ XLogSend(char *msgbuf, bool *caughtup)
679681/*
680682 * Figure out how much to send in one message. If there's no more than
681683 * MAX_SEND_SIZE bytes to send, send everything. Otherwise send
682- * MAX_SEND_SIZE bytes, but round to logfile or page boundary.
684+ * MAX_SEND_SIZE bytes, but roundback to logfile or page boundary.
683685 *
684686 * The rounding is not only for performance reasons. Walreceiver
685687 * relies on the fact that we never split a WAL record across two