Fujii Masao wrote:
> On Fri, May 15, 2009 at 12:36 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote:
>>> On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
>>>
>>>> This whole thing can be considered to be a new feature.
>>> recovery.conf will contain a new optional parameter:
>>>
>>> recovery_end_command (string)
>> Implemented.
>
>> + ereport(signaled ? FATAL : WARNING,
>> + (errmsg("recovery_end_command \"%s\": return code %d",
>> + xlogRecoveryEndCmd, rc)));
>
> In fast failover case, pg_standby has to delete the trigger file immediately
> if it's found. Otherwise, recovery may go wrong as I already described.
> http://archives.postgresql.org/pgsql-hackers/2009-04/msg01139.php
And if you delete it immediately, you risk getting stuck if there's
extra WAL files in pg_xlog. So still need the change in the backend to
not call restore_command again for a WAL segment equal to or later than
one that it already failed to restore. Or, we can truncate the trigger
file to make it behave like a smart failover for the subsequent
pg_standby calls.
> So, in fast mode, recovery_end_command would always fail to delete the
> trigger file, and cause warning. This is odd behavior, I think. We should
> change WARNING to DEBUG2 like RestoreArchivedFile() in the above code?
I think we should just change the pg_standby example to use "rm -f"
rather than "rm". It seems useful to give a warning if the command fails.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
