On Wed, May 25, 2011 at 11:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: >> On 25.05.2011 07:42, Fujii Masao wrote: >>> To achieve that, I'm thinking to change walsender so that, when the standby >>> has caught up with the master, it sends back the message indicating that to >>> the standby. And I'm thinking to add new function (or view like >>> pg_stat_replication) >>> available on the standby, which shows that info. > >> By the time the standby has received that message, it might not be >> caught-up anymore because new WAL might've been generated in the master >> already. > > Even assuming that you believe this is a useful capability, there is no > need to change walsender. It *already* sends the current-end-of-WAL in > every message, which indicates precisely whether the message contains > all of available WAL data.
That's not enough to calculate whether failover is safe or not. Even if the standby's flush location is equal to the master's current end location, new WAL might have already been generated, and the "success" indication of the corresponding transaction might have been returned to the client (this is possible only when async mode). So in addition to the master's current end location, the standby must know its sync mode, which walsender would need to send. Another problem is that, when we can safely promote the standby, the standby's flush location isn't always equal to the master's current end location. Imagine the case where there are some unsent WAL in the master and corresponding transactions are waiting for replication. In this case, obviously those locations are not the same. But in sync replication, we can guarantee that all the committed (from the client's view) transactions have been replicated to the standby, so failover is safe. 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
