Aidan Van Dyk <aidan@highrise.ca> writes:
> *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 ;-)
Agreed *here*, but if you read the threads again, you'll see that's not
at all what's been talked about before my proposal.
In particular, the questions about how to unlock a master's setup while
its synced standby is doing a base backup should not be allowed to
exists, and you seem to agree with my point.
>> 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.
Exactly, even if I didn't dare spell it this way.
What I want to propose is for the user to be able to configure things so
that he loses the sync aspect of the replication if it so happens that
the setup is not able to provide for it.
It may sound strange, but it's needed when all you want is a no stale
data reporting stanbdy, e.g. And it so happens that it's already in
Simon's code, AFAIUI (yet to read it, see).
> 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.
We're on the same track. I don't know how to offer your options without
a clear listing of standby states and transitions, which must include
the synchronicity and whether you just lost it or whatnot.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support