Re: New trigger option of pg_standby

Hi,

On Thu, Apr 9, 2009 at 9:47 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> +       if (strspn(buf, "smart") == 5 && strncmp(buf, "smart", 5) == 0)
>> +       {
>
> The strspn() call seems pointless here.

OK, I'll get rid of it.

>
> One problem with this patch is that in smart mode, the trigger file is not
> deleted. That's different from current pg_standby behavior, and makes
> accidental failovers after one failover more likely.

Yes, it's because pg_standby cannot be sure when the trigger file
can be removed in smart mode. If the trigger file is deleted as soon
as it's found, just like in fast mode, pg_standby may keep waiting
for WAL file again.

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?

Or, do you have any better idea?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center