On 30.11.2012 13:11, Dimitri Fontaine wrote:
Hi,
Heikki Linnakangas<hlinnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
