On Fri, Feb 25, 2011 at 4:36 PM, Josh Berkus <j...@agliodbs.com> wrote:
> Daniel,
>> Ah, okay, I had missed that discussion, I also did not know it got so
>> specific as to address this case (are you sure?) rather than something
>> more general, say quorum or N-safe durability.
> The way we address that case is through n-safe durability.

How is this exposed? The simple "count the number of fsyncs()"
approach is not quite good enough (one has no control to make sure one
or more nodes are definitely up-to-date) unless one wants to just make
it go to *all* syncrep standys for a while. That seems like overkill;
so I imagine something else is in the thoughts. I'll search the

>> The user may have their own level of durability guarantee they want to
>> attain (that's why machine "B" is syncrepped in my example), but when
>> doing the switchover I think an override to enable a smooth handoff
>> (meaning: everything syncrepped) would be best.  What I want to avoid
>> is an ack from "COMMIT" from the primary (machine "A"), and then, post
>> switchover, the data isn't there on machine A-Prime (or "B", provided
>> it was able to follow successfully at all, as in the current case it
>> might get ahead of A-prime in the WAL).
> Yeah, when I think about your use case, I can understand why it's an
> issue.  It would be nice to have a superuser setting (or similar) which
> could override user preferances and make all transactions synchrep
> temporarily.  I'm not sure that's going to be reasonable to do for 9.1
> though.

Agreed; I'd be happy to take any syncrep functionality, although it
wouldn't compose well as-is, I wanted to raise this so that we didn't
make any configuration decisions that got in the way of making
composition possible later.  Again, I haven't thought ahead yet,
partially because I thought there may be some existing thoughts in
play to consider.

With that, I will try to give syncrep a more structured review Real
Soon, although the late date of this is leaving me queasy as to the
odds of git-commit.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to