Re: BUG #5011: Standby recovery unable to follow timeline change
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #5011: Standby recovery unable to follow timeline change |
Дата | |
Msg-id | 4A9627F8.7070208@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #5011: Standby recovery unable to follow timeline change (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
Tom Lane wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> Tom Lane wrote: >>> Specifically, I propose this patch instead. > >> It looks better, but leaves the door open for WAL insertions for a much >> longer period. Particularly, there's the call to CheckpointGuts(), which >> does a lot of things. Maybe I'm just too paranoid about keeping that >> sanity check as tight as possible... > > Well, I'd prefer to go through the LocalSetXLogInsertAllowed/ > reset LocalXLogInsertAllowed dance twice rather than have this code > calling InitXLOGAccess directly (and unconditionally, which was > even worse IMHO). But I don't actually see anything wrong with > having CheckpointGuts enabled to write WAL. I could even see that > being *necessary* in some future iteration of the system --- who's > to say that a checkpoint involves adding only one WAL entry? Yeah. maybe it's OK. There isn't anything strictly wrong about writing WAL records at that time - we already allowed it for the rmgr cleanup routines. CheckpointGuts is shared by recovery points, though, so any WAL insertions in there would be conditional (like "if (in recovery) xloginsert()"). I'll commit your patch then. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: