Re: Sync Rep: First Thoughts on Code

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