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