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
