Daniel, Thanks for writing.
Ah. I'll itemize the rationale: > > Postgres does a system() call to run the archive fetch command, and > blocks until it is complete, then applies the fetched WAL. If one > only does parallelism, the result is that, say, 8 WAL segments will be > downloaded in parallel and then Postgres will apply them...something > that can take some time. And in that time, no downloads are > happening, which is a big loss. > > Indeed. When I woke up this morning, it all made sense. > I'm a bit reticent to do this in the release candidate part of the > release cycle, but we can get on it pronto for 0.9dev and apply the > patch first before more interesting changes go in. I'd recommend, > then, using that. > > That's fine by me. I've already got a package archive containing 0.8c1 and its dependencies, so I don't think you should hold up the release while I putter this out. > Finally, I think I did things this way because one can do "apt-get > install python-daemon" and get the dependency they need on Ubuntus. That is a considerate choice, and indeed, when I first operationalized WAL-E, I, too, reached for the Ubuntu system packages as a means for installing WAL-E's deps. Sadly, some of the OpenStack dependencies didn't line up with what was in Ubuntu 12.04 / 14.04. So it made more sense to materialize all the dependencies into python packages (bdist_eggs. 2014 and all, but really) and just follow a similar path to how we deploy other Python environments. -HJB -- You received this message because you are subscribed to the Google Groups "wal-e" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
