From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby |
Date: | 2009-07-08 15:29:45 |
Message-ID: | 4A54BB69.40007@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao wrote:
> On Wed, Jul 8, 2009 at 4:00 AM, Heikki
> Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> I would envision the slaves
>>> connecting to the master's replication port and asking "feed me WAL
>>> beginning at LSN position thus-and-so", with no notion of WAL file
>>> boundaries exposed anyplace.
>> Yep, that's the way I envisioned it to work in my protocol suggestion
>> that Fujii adopted
>> (http://archives.postgresql.org/message-id/4951108A.5040608@enterprisedb.com)
>> The <begin> and <end> values are XLogRecPtrs, not WAL filenames.
>
> If <begin> indicates the middle of the XLOG file, the file written to the
> standby is partial. Is this OK? After two server failed, the XLOG file
> including <begin> might still be required for crash recovery of the
> standby server. But, since it's partial, the crash recovery would fail.
> I think that any XLOG file should be written to the standby as it can
> be replayed by a normal recovery.
The standby can store the streamed WAL to files in pg_xlog of the
standby, to facilitate crash recovery, but it doesn't need to be exposed
in the protocol.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-07-08 15:41:19 | Re: multi-threaded pgbench |
Previous Message | Alvaro Herrera | 2009-07-08 15:23:32 | Re: multi-threaded pgbench |