Re: New trigger option of pg_standby - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: New trigger option of pg_standby
Date
Msg-id 4A095A39.3030100@enterprisedb.com
Whole thread Raw
In response to Re: New trigger option of pg_standby  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: New trigger option of pg_standby  (Simon Riggs <simon@2ndQuadrant.com>)
Re: New trigger option of pg_standby  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Fujii Masao wrote:
> On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Implementation of GROUPING SETS (T431: Extended grouping capabilities)
Next
From: Simon Riggs
Date:
Subject: Re: New trigger option of pg_standby