Re: Sync Rep: First Thoughts on Code

Simon Riggs wrote:
> * 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.

Does it actually do that? I can see comments suggesting that in 
walreceiver, but I can't find the place in xlog.c where the startup 
process does the waiting.

> * code management
> 
> Other than that there isn't that much in it...

Ok, just making sure I wasn't missing something crucial. I agree it 
should be integrated. What I'm actually worried about is that this 
system isn't integrated enough, and having to set up the archiving, 
pg_standby, and the synchronous repliation itself, correctly, makes it 
too complex to be practical.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com