Re: Sync Rep: First Thoughts on Code

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