Re: Sync Rep: First Thoughts on Code

* Simon Riggs <simon(at)2ndQuadrant(dot)com> [081212 08:20]:
>
> 2. Commit will wait *until* full sync rep is available. So we don't
> allow it until standby fails and also don't allow it if standby goes
> down.
> This provides "Highest Transaction Durability", though is fairly
> fragile. Other systems recommend use of multiple standby nodes if this
> option is selected.

yes please!

> Perhaps we should add this as a third option to synchronous_replication,
> so we have either off, on, only
>
> So far I realise I've been talking exclusively about (1). In that mode
> synchronous_replication = on would wait for streaming to complete even
> if last WAL file not fully transferred.

Seems reasonable...

> For (2) we need a full interlock. Given that we don't currently support
> multiple streamed standby servers, it seems not much point in
> implementing the interlock (2) would require. Should we leave that part
> for 8.5, or do it now?

Ugh... If all sync-rep is gong to give is "if it's working, the commit
made it the slaves, but it might not be working [anymore|yet], but you
(the app using pg) have no way of knowing...", that sort of defeats the
point ;-)

I'ld love multiple slaves, but I understand that's not in the current
work, and I understand that it might be hard with the accept & become
wall-sender approach. It should be very easy to make a walsender handle
"multiple" slaves, and voting of quorum/etc as "successfully on slave",
except that we need to get the multiple connections to the walsender
backend...

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.