| From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Synchronous replication |
| Date: | 2010-07-16 17:26:27 |
| Message-ID: | E3662D1B-98F0-4CA4-A23B-5DE4AF2221E7@hi-media.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Le 16 juil. 2010 à 12:43, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> a écrit :
> On 16/07/10 10:40, Fujii Masao wrote:
>> So we should always prevent the standby from applying any WAL in pg_xlog
>> unless walreceiver is in progress. That is, if there is no WAL available
>> in the archive, the standby ignores pg_xlog and starts walreceiver
>> process to request for WAL streaming.
>
> That completely defeats the purpose of storing streamed WAL in pg_xlog in the first place. The reason it's written and fsync'd to pg_xlog is that if the standby subsequently crashes, you can use the WAL from pg_xlog to reapply the WAL up to minRecoveryPoint. Otherwise you can't start up the standby anymore.
I guess we know for sure that this point has been fsync()ed on the Master, or that we could arrange it so that we know that?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2010-07-16 17:31:19 | Re: SHOW TABLES |
| Previous Message | Andrew Geery | 2010-07-16 17:23:18 | Review: Patch for phypot - Pygmy Hippotause |