Streaming replication, loose ends

I've now committed streaming replication. I moved the files around a
bit, and put the walreceiver/walsender stuff in a new
src/backend/replication subdirectory. There's enough stuff there already
to deserve a new subdirectory, and if we add the capability for
streaming base backups etc. that has been discussed, we will have more
code in there.

But it's not time to party yet. There's still a few loose ends we need
to address:

Documentation. The patch originally moved around some sections, but I
didn't include that in the committed version, to make it clear in the
diff what exactly was added/changed. But I do agree with the original
thought of adding a new "Replication" chapter, and moving all the
replication and standby related stuff there from the "Backup and
Restore" chapter, so let's start working on that.

And of course the documentation needs to be improved and expanded in
general.

We talked about changing the retry-logic yesterday, so that the standby
could fall back to restoring WAL files from archive even after it has
already connected to the primary, if it e.g falls behind too much. It
looks like that involves some heavy refactoring around
ReadRecord/FetchRecord, which makes me a bit nervous given how critical
ReadRecord() is and how old and well-tested the current code is. So
let's tackle that as a follow-on patch.

Then there's the issue of what privileges to require for a replication
connection. I kept the superuser() check for now, so you currently need
to be superuser, but as I opined earlier I don't think that's good for
overall security. Perhaps we should add a new "replication" privilege
besides the login privilege. To connect for replication, replication
privilege would be checked instead of login privilege. That would make
it quite simple to create a user or users for replication purposes, with
no other access to the system.

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