| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Synchronization levels in SR |
| Date: | 2010-05-26 17:49:14 |
| Message-ID: | 4BFD5F1A.9090503@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 26/05/10 20:33, Kevin Grittner wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
>> Although, if the master crashes at that point, and quickly
>> recovers, you could see the last transactions committed on the
>> master before they're replicated to the standby.
>
> Versus having the transaction committed on one or more slaves but
> not on the master? Unless we have a transaction manager and do
> proper distributed transactions, how do you avoid edge conditions
> like that?
Yeah, I guess you can't. You can guarantee that a commit is always
safely flushed first in the master, or in the standby, but without
two-phase commit you can't guarantee atomicity. It's useful to know
which behavior you get, though, so that you can take it into account in
your failover procedure.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2010-05-26 17:59:11 | psql \? \daS |
| Previous Message | Selena Deckelmann | 2010-05-26 17:45:50 | Re: WIP patch for serializable transactions with predicate locking |