| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Markus Wanner <markus(at)bluegap(dot)ch> |
| 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 12:16:12 |
| Message-ID: | AANLkTinNBPHr330-Nz_=cXUke-5EGbtGEOdkdNsAq12U@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 7, 2010 at 4:01 AM, Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> 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.
Right, definitely. The trouble is that if they happen concurrently,
and there's a crash, you have to be prepared for the possibility that
either one of the two has completed and the other is not. In
practice, this means that the master and standby need to compare notes
on the ending WAL location and whichever one is further advanced needs
to stream the intervening records to the other. This would be an
awesome feature, but it's hard, so for a first version, it makes sense
to commit on the master first and then on the standby after the master
is known done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2010-09-07 12:27:23 | Re: returning multiple result sets from a stored procedure |
| Previous Message | Robert Haas | 2010-09-07 12:09:54 | Re: can we publish a aset interface? |