On Thu, 4 Jun 2009, Geoffrey wrote:
> For now, I'm still looking at the other tools as well as attempting to verify
> that my current solution doesn't miss any 'little issues.'
The main thing you want to test out are that it acts sanely when the
network connection to the destination server is out, and that it doesn't
go insane if either the source or destination server run out of disk
space. You should simulate both of those things.
The important thing is to validate your script cannot say you've processed
an archive file until you're absolutely positive it's stored somewhere
safe. It's really not that hard. If you've got practice writing robust
system scripts already, and it sounds like you do, I wouldn't hesitate to
use a homegrown solution here instead of walmgr/pitrtools as long as
you've done the tests I outline here.
> I assume a script that pulls the logs to the warm standby and then calls
> pg_standby.
The way you say this makes me think you haven't really absorbed how
pg_standby works yet. You don't call it; the database recovery script
does. Your program's interaction with it is merely to drop files into the
place it expects them to be (atomically), it's a polling solution that
alternates between looking for files there/applying them to the
database/sleeping when there's no more left.
If you've already gone to the trouble of writing all the pieces here
yourself, it really shouldn't be difficult to yank out the parts
pg_standby does and use it for those instead. There's a few things in
there you'll have a hard time implementing yourself that probably aren't
even on your radar yet, but are nonetheless important. Being able to keep
standby disk usage pruned easily with the restartwalfile feature comes to
mind, that one is a subtle problem that doesn't sneak up on you until
you've been in production a while.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD