On Wed, 2008-12-10 at 21:02 +0200, Heikki Linnakangas wrote: > 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.
Not yet... we agreed it would do that a few days ago. This thread, Fri 5 Dec. > > * 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 replication itself, correctly, makes it > too complex to be practical. I'm worried about the complexity also. If we didn't use the existing archiving mechanism we'd need to invent something that looks just like it. If I could get rid of pg_standby as well, I would. I've got no qualms about chopping stuff I wrote, as long as we do it for a good reason. Keeping the parts of the old model that make sense means less code and less process change for existing users. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
