Hi, On Fri, Apr 10, 2009 at 6:31 PM, Guillaume Smet <guillaume.s...@gmail.com> wrote: > On Fri, Apr 10, 2009 at 5:47 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> One idea to solve this problem is to tell pg_standby as a >> command-line argument about whether the trigger file can be >> removed. That parameter value can be set to 'true' when the last >> applied record is re-fetched. Though pg_standby is called to >> restore timeline history files also after that point, the trigger file >> is already unnecessary (pg_standby doesn't wait for history file). >> >> Specifically, if restore_command contains new % option (%e?), >> it's replaced by the boolean value which indicates whether the >> trigger file can be deleted. This value is set to 'true' when the >> startup process re-fetches the last valid record, 'false' otherwise. >> In smart mode, pg_standby determines whether to delete the >> trigger file according to that value. >> >> Comments? > > Hmmm, it seems overly complicated but I don't know the code of pg_standby.
Yes, I'd also like to simplify it more. >> Or, do you have any better idea? > > Wouldn't it be possible to have a global switch (let's name it > startCluster, default to false) which is set to true when the trigger > file is found for the first time? You would then be able to remove the > trigger file and let the cluster start by checking this variable. > > One more time, I don't know the code of pg_standby so it may be a stupid idea. Thanks for the suggestion! Since pg_standby is executed for each file, such variable cannot be taken over to the next execution, i.e. it's reset each time. So, the current patch have left the trigger file until the end. 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
