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. We could prevent that by fsyncing all WAL before applying it - presumably fsyncing a file that has already been flushed is quick. But is it worth the trouble?
walreceiver.c/* Wait a while for data to arrive */ if (walrcv_receive(NAPTIME_PER_CYCLE,&type,&buf,&len)) { /* Accept the received data, and process it */ XLogWalRcvProcessMsg(type, buf, len); /* Receive any more data we can without sleeping */ while (walrcv_receive(0,&type,&buf,&len)) XLogWalRcvProcessMsg(type, buf, len); /* * If we've written some records, flush them to disk and let the * startup process know about them. */ XLogWalRcvFlush(); }The problematic case happens when the latter walrcv_receive emits ERROR. In this case, the WAL received by the former walrcv_receive is not guaranteed to have been flushed yet. The attached patch ensures that all WAL received is flushed to disk before walreceiver exits. This patch should be backported to 9.0, I think.
Yeah, we probably should do that, even though it doesn't completely close the window tahat unsynced WAL is replayed.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
