Re: Refactoring standby mode logic - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Refactoring standby mode logic
Date
Msg-id 50BC812B.9010400@vmware.com
Whole thread Raw
In response to Re: Refactoring standby mode logic  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Refactoring standby mode logic
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Refactoring standby mode logic
Next
From: Amit Kapila
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL