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

In response to

• Re: New trigger option of pg_standby at 2009-04-21 12:55:10 from Heikki Linnakangas

pgsql-hackers by date

Next:	From: Dickson S. Guedes	Date: 2009-04-21 14:11:54
	Subject: Re: Automating Partitions in PostgreSQL - Query on syntax
Previous:	From: Kedar Potdar	Date: 2009-04-21 14:03:10
	Subject: Re: Automating Partitions in PostgreSQL - Query on syntax