On Thu, Oct 7, 2010 at 10:08 AM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Aidan Van Dyk <ai...@highrise.ca> writes: >> Sure, but that lagged standy is already asynchrounous, not >> synchrounous. If it was synchronous, it would have slowed the master >> down enough it would not be lagged. > > Agreed, except in the case of a joining standby.
*shrug* The joining standby is still asynchronous at this point. It's not synchronous replication. It's just another ^k of the N slaves serving stale data ;-) > But you're saying it > better than I do: > >> Yes, I believe you need to have a way for an admin (or >> process/control/config) to be able to "demote" a synchronous >> replication scenario into async (or "standalone", which is just an >> extension of really async). But it's no longer syncronous replication >> at that point. And if the choice is made to "keep trucking" while a >> new standby is being brought online and available and caught up, >> that's fine too. But during that perioud, until the slave is caught >> up and synchrounously replicating, it's *not* synchronous replication. > > That's exactly my point. I think we need to handle the case and make it > obvious that this window is a data-loss window where there's no sync rep > ongoing, then offer users a choice of behaviour. Again, I'm stating there is *no* choice in synchronous replication. It's *got* to block, otherwise it's not synchronous replication. The "choice" is if you want synchronous replication or not at that point. And turning it off might be a good (best) choice for for most people. I just want to make sure that: 1) There's now way to *sensibly* think it's still "synchronously replicating" 2) There is a way to enforce that the commits happening *are* synchronously replicating. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers