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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
