Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Greg Smith <greg@2ndquadrant.com>

From: Greg Smith <greg@2ndquadrant.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Simon Riggs <simon@2ndQuadrant.com>, Dimitri Fontaine <dfontaine@hi-media.com>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-02-11T14:55:11Z
Lists: pgsql-hackers
Heikki Linnakangas wrote:
> Simon Riggs wrote:
>   
>> Might it not be simpler to add a parameter onto pg_standby?
>> We send %s to tell pg_standby the standby_mode of the server which is
>> calling it so it can decide how to act in each case.
>>     
>
> That would work too, but it doesn't seem any simpler to me. On the contrary.
>   

I don't know that the ideas are mutually exclusive.  Should the server 
internals do a basic check that the files they're about to process seem 
sane before processing them?  Yes.  Should we provide a full-featured 
program that knows how far back it can delete archives rather than 
expecting people to write their own?  Yes.  And a modified pg_standby 
seems the easiest way to do that, since it already knows how to do the 
computations, among other benefits.

I already have a work in progress patch to pg_standby I'm racing to 
finish here that cleans up some of the UI warts in the program, 
including the scary sounding and avoidable warnings Selena submitted a 
patch to improve.  I think I'm going to add this feature to it, too, 
whether or not it's deemed necessary.  I'm really tired of example 
setups provided that say "just write a simple script using cp like 
<trivial example>" and then supporting those non-production quality 
messes in the field.  My scripts for this sort of thing have more error 
checking in them than functional code.  And pg_standby already has a 
healthy sense of paranoia built into it.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us