* Simon Riggs <si...@2ndquadrant.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, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
