Re: write ahead logging in standby (streaming replication)

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: write ahead logging in standby (streaming replication)
Date: 2009-11-12 04:31:23
Message-ID: 3f0b79eb0911112031w6bf54d80r89957de9f90c6487@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 12, 2009 at 12:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>> Should the standby also have to follow the WAL rule during recovery?
>> The current patch doesn't care about the write order of the data page
>> and WAL in the standby. So, after both servers fail, restarting the
>> ex-standby by itself might corrupt the data.
>
> Surely the receiver should fsync the WAL itself to disk before
> acknowledging it.  Assuming you've done that, I don't see any
> corruption risk.

"acknowledging it" means "letting the startup process know the arrival
of WAL records"? If so, I agree that there is no risk of data corruption.

The problem is that fsync needs to be issued too frequently, which would
be harmless in asynchronous replication, but not in synchronous one.
A transaction would have to wait for the primary's and standby's fsync
before returning a "success" to a client.

So I'm inclined to change the startup process and bgwriter, instead of
walreceiver, so as to fsync the WAL for the WAL rule.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message A.M. 2009-11-12 04:36:46 Re: Listen / Notify rewrite
Previous Message Andrew Chernow 2009-11-12 03:45:23 Re: Listen / Notify rewrite