Hi, On Mon, Apr 20, 2009 at 6:06 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Fujii Masao wrote: >> >> On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao <masao.fu...@gmail.com> >> wrote: >>> >>> I'd like to propose another simple idea; pg_standby deletes the >>> trigger file *whenever* the nextWALfile is a timeline history file. >>> A timeline history file is restored at the end of recovery, so it's >>> guaranteed that the trigger file is deleted whether nextWALfile >>> exists or not. >>> >>> A timeline history file is restored also at the beginning of >>> recovery, so the accidentally remaining trigger file is deleted >>> in early warm-standby as a side-effect of this idea. >> >> Here is the revised patch as above. > > I think we have gone off to an overly complicated solution. pg_standby > shouldn't need to special-case history files, or know what order the server > will ask for them. > > What's wrong with just this: (ignoring the missing fast option) > > --- a/contrib/pg_standby/pg_standby.c > +++ b/contrib/pg_standby/pg_standby.c > @@ -552,8 +552,6 @@ main(int argc, char **argv) > break; > case 't': /* Trigger file */ > triggerPath = optarg; > - if (CheckForExternalTrigger()) > - exit(1); /* Normal exit, with non-zero */ > break; > case 'w': /* Max wait time */ > maxwaittime = atoi(optarg); > > ie. only check and delete the trigger file once the server requests a file > that doesn't exist.
Thanks for the suggestion! I have three comments. 1) Though some users want to save the fast failover mode, this solution doesn't provide it. You think that that mode is unnecessary? 2) This solution would go wrong when there are the WAL files in pg_xlog; If pg_xlog of the primary server can be read at failover (it's not node failure but process failure case), the WAL files in it may be copied to pg_xlog of the standby server in order to prevent the transaction loss. On the other hand, we can copy such files to the archival storage instead of pg_xlog. In this case, your simple solution goes well, but recovery would unexpectedly end without the trigger file because those WAL files have the invalid record which means the end of WAL. I'd like to control when the standby will come up as a normal server. So, I think that pg_standby should cope with also the above situation which I described. What is your opinion? 3) This solution has a race condition; some transactions would be lost if WAL file is shipped from the primary server and the trigger file is created, while pg_standby is sleeping, because pg_standby checks previously whether a trigger file exists. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
