From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Daniel Farina <daniel(at)heroku(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: disposition of remaining patches |
Date: | 2011-02-25 23:44:39 |
Message-ID: | 4D683EE7.4090507@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
http://www.pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-02-26 00:00:11 | Re: wCTE: about the name of the feature |
Previous Message | Josh Berkus | 2011-02-25 23:41:09 | Re: WIP: cross column correlation ... |