On 13.01.2011 12:35, Fujii Masao wrote:
On Thu, Jan 13, 2011 at 5:59 PM, Heikki Linnakangas
<heikki.linnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
