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

From Guillaume Smet
Subject Re: New trigger option of pg_standby
Date
Msg-id 1d4e0c10904100231p43aecd0fhdae48f732d9f264d@mail.gmail.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  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Fri, Apr 10, 2009 at 5:47 AM, Fujii Masao <masao.fujii@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.

> 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.

-- 
Guillaume


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Missing mapping in 8.3/tsearch2.sql
Next
From: Tom Lane
Date:
Subject: Re: pg_restore dependencies