Re: New trigger option of pg_standby

Fujii Masao wrote:
> On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> This is getting complicated, though. I guess it would be enough to document
>> that you mustn't copy any extra files into pg_xlog if you use a fast
>> trigger.
>
> Agreed. I added this note into document.
>
> Attached is the updated patch. I also fixed my bug which
> pg_standby returns 0 even if the requested file fails to be
> restored in smart mode.
>
> This patch is ready to commit, I think. Please review this.

Looking at this again..

Deleting the trigger file when a history file is requested:

> /*
> * Get rid of the trigger file at the end of archive recovery.
> * Otherwise, it would unexpectedly cause the subsequent warm-standby to
> * end.
> *
> * Here is the right place to remove the trigger file since a timeline
> * history file is requested only at the beginning and end of archive
> * recovery.
> */

changes the behavior in a subtle way: if you create trigger file before
starting recovery, it will be deleted when the recovery is started and
no failover is done. Currently, it will end the recovery immediately.

That makes me uncomfortable to back-patch this. That change in behavior
might be hard to work-around: the process that creates the trigger file
would have to make sure that the server has started recovery before
creating the file.

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?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com