| From: | Markus Wanner <markus(at)bluegap(dot)ch> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Synchronization levels in SR |
| Date: | 2010-09-07 08:01:20 |
| Message-ID: | 4C85F150.1010305@bluegap.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 05/27/2010 01:28 PM, Robert Haas wrote:
> How do you propose to guarantee that? ISTM that you have to either
> commit locally first, or send the commit to the remote first. Either
> way, the two events won't occur exactly simultaneously.
I'm not getting the point of this discussion. As long as the database
confirms the commit to the client only *after* having an ack from the
standby and *after* committing locally, there's no problem.
In any case, a server failure in between the commit request of the
client and the commit confirmation for the client results in a client
that can't tell if its transaction committed or not.
So why do we care what to do first internally? Ideally, these two tasks
should happen concurrently, IMO.
Regards
Markus Wanner
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Markus Wanner | 2010-09-07 08:22:51 | Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!) |
| Previous Message | Dean Rasheed | 2010-09-07 07:43:50 | Re: WIP: Triggers on VIEWs |