Re: [PATCH] A crash and subsequent recovery of themaster can cause the slave to get out-of-sync - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: [PATCH] A crash and subsequent recovery of themaster can cause the slave to get out-of-sync
Date
Msg-id 468D496D.4020409@phlo.org
Whole thread Raw
In response to Re: [PATCH] A crash and subsequent recovery of themaster can cause the slave to get out-of-sync  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Tom Lane wrote:
>>> Conclusion: we should apply Florian's patch as-is in 8.2, do something
>>> morally equivalent in 8.1 and before, and invent a
>>> CrashRecoveryCheckpoint record type in HEAD.
> 
>> Sounds good.
> 
> Actually, now that I look closer, this patch seems completely wrong.
> It's predicated on an assumption that rm_cleanup won't write WAL entries
> describing what it did ... but, at least in the btree case, it does.
> (I think gist/gin might not, but that's a bug in those AMs not in xlog.)
> I'm therefore wondering what test case led you to think there was
> something wrong.

It wasn't a testcase - I was trying to understand the xlog code while working
on my concurrent walreplay patch, and wondered what happens if the master 
crashes and then recovery while the slave keeps running.

I've re-read my original email to Simon, and it seems that I believed
that rm_cleanup methods won't bee able to write to the xlog because they are
called during recovery.

But StartupXLOG *does* make the wal append able *before* the rm_cleanup methods
are called.

So I now think (at least for btree) that everything is fine, and that I was
just being stupid.

Sorry for the noise, guys
greetings, Florian Pflug



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: usleep feature for pgbench
Next
From: Jan Wieck
Date:
Subject: Re: usleep feature for pgbench