Fujii Masao wrote:
> On Tue, May 12, 2009 at 8:15 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Here's another idea: Let's modify xlog.c so that when the server asks for
>> WAL file X, and restore_command returns "not found", the server will not ask
>> for any WAL files >= X again (in that recovery session). Presumably if X
>> doesn't exist, no later files will exist either. That would be pretty simple
>> change, and it would allow us to go with the simpler implementation in
>> pg_standby and just remove the trigger file immediately when it returns "not
>> found" (instead of removing it when history file is requested). That would
>> make it safe to copy extra WAL files into pg_xlog, even in fast failover
>> mode.
>>
>> Does anyone see a hole in that idea?
>
> Probably yes. The trigger file would remain after failover if the
> restored WAL file has the invalid record which means the end
> of WAL. In this case, "not found" is not returned.
Yep. That's not pleasant either :-(.
I don't think we're going to get this to work reliably without extending
the interface between the backend and restore_command. We've discussed
many methods and there's always some nasty corner-case like that.
I think we should leave back-branches as is, and go with Simon's
suggestion to add new "recovery_end_command" that's run when the
recovery is finished. That's simpler and more reliable than any of the
other approaches we've discussed, and might become handy for other
purposes as well.
Does someone want to take a stab at writing a patch for that?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com