| From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Markus Wanner" <markus(at)bluegap(dot)ch>, "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Synchronous Log Shipping Replication |
| Date: | 2008-09-10 08:15:59 |
| Message-ID: | 2e78013d0809100115r4fcd801hfb96194121def9ac@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 10, 2008 at 1:40 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
>
> The thing that bothers me is the behavior when the synchronous slave doesn't
> respond. A timeout has been discussed, after which the master just gives up
> on sending, and starts acting as if there's no slave. How's that different
> from asynchronous mode where WAL is sent to the server concurrently when
> it's flushed to disk, but we don't wait for the send to finish? ISTM that in
> both cases the only guarantee we can give is that when a transaction is
> acknowledged as committed, it's committed in the master but not necessarily
> in the slave.
>
I think there is one difference. Assuming that the timeouts happen
infrequently, most of the time the slave is in sync with the master
and that can be reported to the user. Whereas in async mode, the slave
will *always* be out of sync.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2008-09-10 08:24:01 | Re: Synchronous Log Shipping Replication |
| Previous Message | Hannu Krosing | 2008-09-10 08:10:38 | Re: Synchronous Log Shipping Replication |