Re: New trigger option of pg_standby

On Tue, 2009-04-21 at 15:55 +0300, Heikki Linnakangas wrote:
> Fujii Masao wrote:
> > On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas
> > <heikki(dot)linnakangas(at)enterprisedb(dot)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.

Agreed. Fujii-san's proposal is the only one that covers all the
important things. The assumptions need careful documentation, as you
say.

The idea of a restore_completion_command does still sound attractive,
easy to implement and non-intrusive enough to do so right now.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support