> Right now, as it stands, the syncrep patch will be happy as soon as
> the data has been fsynced to either B or A-prime; I don't think we can
> guarantee at any point that A-prime can become the leader, and feed B.

Yeah, I think that's something we said months ago is going to be a 9.2
feature, no sooner.

> 2. The unprivileged user can disable syncrep, in any situation. This
> flexibility is *great*, but you don't really want people to do it when
> one is performing the switchover. Rather, in a magical world we'd hope
> that disabling syncrep would just result in not having to
> synchronously commit to B (but, in this case, still synchronously
> commit to A-prime)
> In other words, to my mind, you can use syncrep as-is to provide
> 2-safe durability xor a scheduled switchover: as soon as someone wants
> both, I think they'll have some trouble. I do want both, though.

Hmmm, I don't follow this.  The user can only disable syncrep for their
own transactions.   If they don't care about the persistence of their
transaction post-failover, why should the DBA care?

                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.

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

Reply via email to