Re: Sync Rep: First Thoughts on Code

> If this is right, #2, #3, #4, and #6 feel similar except
> that they're protecting against failures of different (but
> still all incomplete) subsets of the hardware on the slave, right?

Right. Actually, the biggest difference with #6 has nothing to do
with protecting against failures. It has rather to do with the ease
of writing applications in the context of hot standby. You can close
your connection, open a connection to a different server, and know
that your transactions will be reflected there. On the other hand,
I'd be surprised if it didn't come with a substantial performance
penalty, so it may not be too practical in real life even if it sounds
good on paper.

#1 , #3, and #5 don't feel that useful to me. In the case of #1,
sending your WAL over the network and then not checking that it got
there is sort of silly: the likelihood of packet loss on the network
has got to be several orders of magnitude more likely than a failure
on the master. #3 and #5 just don't seem to provide any real benefits
over their immediate predecessors.

Honestly, I think the most useful thing is probably going to be
asynchronous replication: in other words, when a commit is requested
on the master, we write WAL and return success. In the background, we
stream the WAL to a secondary, which writes it and applies it. This
will give us a secondary which is mostly up to date (and can run
queries, with hot standby) without killing performance. The other
options are going to be for environments where losing a transaction is
really, really bad, or (in the case of #6) read-mostly environments
where it's useful to spread the query load out across several servers,
but the overhead associated with waiting for the rare write
transactions to apply everywhere is tolerable.

...Robert