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

From Dimitri Fontaine
Subject Re: Refactoring standby mode logic
Date
Msg-id m2sj7rbb0h.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Refactoring standby mode logic  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Refactoring standby mode logic  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
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.

> 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.

Is it possible for your refactoring to keep the old sequence?

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support




pgsql-hackers by date:

Previous
From: Ibrar Ahmed
Date:
Subject: Review: create extension default_full_version
Next
From: Alexander Korotkov
Date:
Subject: Re: WIP: index support for regexp search