On Wed, 2008-12-10 at 14:39 +0200, Heikki Linnakangas wrote:
> In the current form, is there any reason why walreceiver needs to be
> an integrated server process? Couldn't it just be a stand-alone
> program that connects to the primary and writes the received records
> to the right WAL file? The only reason I can see is to reliably kill
> it when the standby server is promoted to primary.
Reasons:
* integration: we have one service we stop and start, not two. We want
one log, one set of commands, one set of parameters etc
* cooperation: if wal receiver is a server process we can reasonably
communicate the current WAL limit via shared memory. That gives us
smooth flow of WAL between receiver and replay (startup process) rather
than a burst of activity each time a file arrives. That helps smooth
performance and minimises failover time. Without this we would need to
retain the concept of archive_timeout on the primary even when
streaming, which is fairly strange.
* code management
Other than that there isn't that much in it...
We've all read the stuff about how other RDBMS come with integrated
replication. We *can* make this integrated, robust and very very easy to
use, yet with flexibility for a variety of purposes.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
