On 13.01.2011 12:35, Fujii Masao wrote:
> On Thu, Jan 13, 2011 at 5:59 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> On 13.01.2011 10:28, Fujii Masao wrote:
>>>
>>> When the master shuts down or crashes, there seems to be
>>> the case where walreceiver exits without flushing WAL which
>>> has already been written. This might lead startup process to
>>> replay un-flushed WAL and break a Write-Ahead-Logging rule.
>>
>> Hmm, that can happen at a crash even with no replication involved. If you
>> "kill -9 postmaster", and some WAL had been written but not fsync'd, on
>> crash recovery we will happily recover the unsynced WAL.
>
> Right. If postmaster restarts immediately after kill -9, WAL which has not
> reached to the disk might be replayed. Then if the server crashes when
> min recovery point indicates such an unsynced WAL, the database would
> get corrupted.
>
> As you say, that is not just about replication. But that is more likely to
> happen in the standby because unsynced WAL appears while recovery
> is in progress. This is one of reasons why walreceiver doesn't let the
> startup process know that new WAL has arrived before flushing it, I think.
>
> So I believe that the patch is somewhat worth applying.
Agreed, Committed.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
