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