| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Sync Rep: First Thoughts on Code |
| Date: | 2008-12-11 07:44:15 |
| Message-ID: | 4940C4CF.7070600@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs wrote:
> When the WAL starts streaming the *primary* can immediately perform
> synchronous replication, i.e. commit waits for transfer.
Until the standby has obtained all the missing log files, it's not
up-to-date, and there's no guarantee that it can finish the replay. For
example, imagine that your archive_command is an scp from the primary to
the standby. If a lightning strikes the primary before some WAL file has
been copied over to the archive directory in the standby, the standby
can't catch up. In the primary then, what's the point for a commit to
wait for transfer, if the reply from the standby doesn't guarantee that
the transaction is safe in the standby?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alif Isophoqote | 2008-12-11 08:29:56 | Debug crash |
| Previous Message | Rushabh Lathia | 2008-12-11 07:37:32 | Re: Function with default value not replacing old definition of the function |