There are several approaches on replication/failover – you might have heard of Slony, Londiste, pgPool and some other tools.
WAL Replication is different from all of them in one aspect – it doesn't let you query slave database (until 9.0, in which you actually can run read only queries on slave.
Since you can't run queries on slave, what is it good for? Well. It's good, and great in 1 very important aspect – all things that happen in database are replicated. Schema changes. Sequence modifications. Everything.
There is also drawback – you can't (as of now) replicate just one database. You replicate whole cluster (I don't like this word in this context – let's say: whole installation) of PostgreSQL. All databases that reside in given DATA directory.
So, the question is – how to set it up?
Continue reading Setting WAL Replication
I tend to write about new features in new versions of PostgreSQL, but this patch actually fixes one of the things that annoy me a lot, so here it goes:
On 26th of January, Simon Riggs committed:
Fix longstanding gripe that we check for 0000000001.history at start of
archive recovery, even when we know it is never present.
If you've ever tried to roll your own restore_command script ( like pg_standby ) then you know that to the algorithm that's presented in docs You always had to add special case for file “0000000001.history" – which was never there, but somehow PostgreSQL always asked for it – despite the fact that it could never arrive.
Now, thanks to this small patch we will no longer need to add this “if" in any script. It's small, and it's not a new feature, but I am SO happy to see it.