On Fri, Nov 13, 2009 at 11:54 AM, Greg Stark <gsst...@mit.edu> wrote: > 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.
Agreed. > 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? If the connection is not closed, the resending is not required because TCP would guarantee that such records arrive at the standby someday. Otherwise, the standby re-connects to the primary, and asks for the missing records, so the resending would be done. Since only the missing records are requested, the already received records don't reach the standby again, I think. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
