Fujii Masao wrote:
> On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Simon Riggs wrote:
>>> What you propose is *better* than raw pg_standby is now, but still not
>>> enough in all cases, as I think you know.
>> No, I don't. What is the case where it doesn't work?
>
> It's the case which I described as the 2nd comment to your
> proposal.
>
> 1. pg_standby tries to restore a non-existent file
> 1-1. remove the trigger file
> 1-2. pg_standby exits with non-zero code
> 2. the startup process tries to read it from pg_xlog
> 2-1. it is applied
> 3. the startup process tries to restore the next file using pg_standby
> 3-1. pg_standby gets *stuck* since the requested file and trigger file
> don't exist.
Ahh, ok, I didn't understand the issue correctly before.
But wait a minute, we already have exactly the same problem with the
current 8.2/8.3 pg_standby, don't we? [tests]. Yes, we do.
Simon's suggestion of a separate restore_completion_command is very
attractive as it would provide an explicit place to hook up the deletion
of the trigger file. It seems useful anyway, you might want to put a
command there to e.g update a log file or launch some custom daemon
software when the recovery ends. The question then is what to do with
8.2 and 8.3? Even if we decided to keep the behavior that the failover
is triggered immediately (fast mode), pg_standby getting stuck if you
copy any WAL files directly into pg_xlog seems like a bug that needs to
be fixed.
Fujii's idea of deleting the trigger file when history file is requested
is the only proposal this far that works and doesn't require changes to
people's config files, so I guess that's what we'll have to do at least
for back-branches.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
