From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: write ahead logging in standby (streaming replication) |
Date: | 2009-11-13 02:54:31 |
Message-ID: | 407d949e0911121854ob2a7b5v92dd983f23b65cc@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 13, 2009 at 2:37 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> Umm... what is your definition of "synchronous"? I'm planning to provide
> four synchronization modes as follows, for v8.5. Does this fit in your
I think my definition would be that a query against the replica will
produce the same result as a query against the master -- and that that
will be the case even after a system failure. That might not
necessarily mean that the log entry is fsynced on the replica, only
that it's fsynced in a location where the replica will have access to
it when it runs recovery.
I do have a different question though. What do you plan to do if
there's a failure when they're out of sync? The master hasn't
responded to the commit yet because it's still waiting on the replica
to respond but it has already recorded the commit itself. When it
comes back up it's out of sync with the replica and has to resend
those records? What if the replica has already received it and it was
the confirmation which was lost?
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-11-13 03:10:24 | Re: next CommitFest |
Previous Message | Robert Haas | 2009-11-13 02:52:34 | Re: EOL for 7.4? |