| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Synchronization levels in SR |
| Date: | 2010-05-26 17:24:47 |
| Message-ID: | 4BFD595F.6070401@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 26/05/10 20:10, Kevin Grittner wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
>> One way to do that would be to refrain from flushing the commit
>> record to disk on the master until the standby has acknowledged
>> it.
>
> I'm not clear on the benefit of doing that, versus flushing the
> commit record and then waiting for responses. Either way some
> databases will commit before others -- what is the benefit of having
> the master lag?
Hmm, I was going to answer that that way no other transactions can see
the transaction as committed before it has been safely replicated, but I
now realize that you could also flush, but refrain from releasing the
entry from procarray until the standby acknowledges the commit, so the
transaction would look like in-progress to other transactions in the
master until that.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-05-26 17:26:28 | Re: Synchronization levels in SR |
| Previous Message | Heikki Linnakangas | 2010-05-26 17:17:31 | Re: Exposing the Xact commit order to the user |