Skip site navigation (1) Skip section navigation (2)

Re: New trigger option of pg_standby

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New trigger option of pg_standby
Date: 2009-04-21 14:05:51
Message-ID: 1240322751.23905.244.camel@ebony.fara.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group