matzko
Compress on the fly during each step instead of at the end
This removes the compression at the end and instead creates a compressed file right from the beginning if possible (using gzopen/gzclose). The reason why I changed this was that on one installation over time the backup files got so large that I got an out of memory error in the delivery step when wp-db-backup tried to load the whole file content into memory so the backup wasn't sent per mail anymore and also couldn't be downloaded anymore. At least on this system the changed version works just fine and I couldn't notice any slowdown of the individual backup steps.
Was this merged into master? I'm having a problem where one install with a large database won't email the backup anymore (download works fine). A second installation with a much smaller database on the same server emails the backup without issue.
I am wondering if this is a similar issue. I am running out of probably causes.
As far as I'm aware these changes have never been applied. However when I implemented these changes the released version of wp-db-backup also didn't try to use to external gzip program and didn't increase the memory limit yet, if the external gzip program can be used on your system I doubt that compressing the backup is the problem in your case.
Furthermore as your problems only concern sending mails and you can download the compressed backup I doubt this is the same problem.
Maybe there is some size limit for sending mails?
The plugin used to compress incrementally, but I removed that functionality a while ago because it caused the file to mis-report its uncompressed size, which in turn caused de-compression to fail for some gzip clients (from memory, I think it was the Mac gzip tool).
