Re: New trigger option of pg_standby

Поиск
Список
Период
Сортировка
От Guillaume Smet
Тема Re: New trigger option of pg_standby
Дата
Msg-id 1d4e0c10904100231p43aecd0fhdae48f732d9f264d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New trigger option of pg_standby  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: New trigger option of pg_standby  (Fujii Masao <masao.fujii@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Missing mapping in 8.3/tsearch2.sql
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_restore dependencies