Synchronous replication, reading WAL for sending

As the patch stands, whenever XLOG segment is switched in XLogInsert, we 
wait for the segment to be sent to the standby server. That's not good. 
Particularly in asynchronous mode, you'd expect the standby to not have 
any significant ill effect on the master. But in case of a flaky network 
connection, or a busy or dead standby, it can take a long time for the 
standby to respond, or the primary to give up. During that time, all WAL 
insertions on the primary are blocked. (How long is the default TCP 
timeout again?)

Another point is that in the future, we really shouldn't require setting 
up archiving and file-based log shipping using external scripts, when 
all you want is replication. It should be enough to restore a base 
backup on the standby, and point it to the IP address of the primary, 
and have it catch up. This is very important, IMHO. It's quite a lot of 
work to set up archiving and log-file shipping, for no obvious reason. 
It's really only needed at the moment because we're building this 
feature from spare parts.

For those reasons, we need a way to send arbitrary ranges of WAL from 
primary to standby. The current method where the WAL is read from 
wal_buffers obviously only works for very recent WAL pages that are 
still in wal_buffers. The design should be changed so that instead of 
reading from wal_buffers, the WAL is read from filesystem.

Sending directly from wal_buffers can be provided as a fastpath when 
sending recent enough WAL range, but I wouldn't bother complicating the 
code for now.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com