Re: Refactoring standby mode logic
От | Heikki Linnakangas |
---|---|
Тема | Re: Refactoring standby mode logic |
Дата | |
Msg-id | 50BC812B.9010400@vmware.com обсуждение исходный текст |
Ответ на | Re: Refactoring standby mode logic (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Refactoring standby mode logic
|
Список | pgsql-hackers |
On 30.11.2012 13:11, Dimitri Fontaine wrote: > Hi, > > Heikki Linnakangas<hlinnakangas@vmware.com> writes: >> Attached is a patch to refactor that logic into a more straightforward state >> machine. It's always been a kind of a state machine, but it's been hard to >> see, as the code wasn't explicitly written that way. Any objections? > > On a quick glance over, looks good to me. Making that code simpler to > read and reason about seems a good goal. Thanks. >> This change should have no effect in normal restore scenarios. It'd only >> make a difference if some files in the middle of the sequence of WAL files >> are missing from the archive, but have been copied to pg_xlog manually, and >> only if that file contains a timeline switch. Even then, I think I like the >> new order better; it's easier to explain if nothing else. > > I'm not understanding the sequence difference well enough to comment > here, but I think some people are currently playing tricks in their > failover scripts with moving files directly to the pg_xlog of the server > to be promoted. That's still perfectly ok. It's only if you have a diverged timeline history, and you have files from one timeline in the archive and files from another in pg_xlog that you'll see a difference. But in such a split situation, it's quite arbitrary which timeline recovery will follow anyway, I don't think anyone can sanely rely on either behavior. > Is it possible for your refactoring to keep the old sequence? Hmm, perhaps, but I think it would complicate the logic a bit. Doesn't seem worth it. Committed.. - Heikki
В списке pgsql-hackers по дате отправления: