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