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

Поиск
Список
Период
Сортировка
От Florian G. Pflug
Тема Re: [PATCH] A crash and subsequent recovery of themaster can cause the slave to get out-of-sync
Дата
Msg-id 468D496D.4020409@phlo.org
обсуждение исходный текст
Ответ на 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: usleep feature for pgbench
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: usleep feature for pgbench