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.comPostgreSQL Training, Services and Support
