On Fri, Nov 21, 2008 at 12:15 AM, Pavan Deolasee <[EMAIL PROTECTED]> wrote: > > > On Thu, Nov 20, 2008 at 8:36 PM, Heikki Linnakangas > <[EMAIL PROTECTED]> wrote: >> >> That seems like a dangerous assumption. What if the standby had fallen >> behind before the failover? It's not safe to failover back to the original >> primary in that case. We'd need some kind of safeguards against that. >> > > For synchronous replication, what if we ensure that the standby has received > the WAL (atleast in its buffers) before writing it to disk on the primary ? > If we do that, I think the old standby can never fall behind the primary and > it would be easy for the old primary to join back the replication without a > fresh backup.
In the current patch, since the WAL are written and sent concurrently for the performance gain, we cannot guarantee whether the old standby fall behind or not. I think that the setup procedure which can resolve both cases is required. > Of course, this doesn't work for async replication. Yeah, in asynch replication, some committed transaction may disappear regardless of whether the fresh backup is used or not. But, since the current patch guarantee "Replicate Ahead Log" rule even if asynch case, we can recover the old primary by using the WAL on the old standby consistently. 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
