Jean-Louis-
It looks like that did the trick. I'll test a little more and let you
know for sure, but it correctly produced a "dumps way to big, must
skip incremental dumps" error and ran the rest of the dumps last night
after I applied the patch.
Thanks!
-Darrell
On Apr 23, 2008, at 8:19 AM, Jean-Louis Martineau wrote:
Darrell,
Thanks for reporting the problem.
Can you try the attached patch?
Jean-Louis
Telsin wrote:
I noticed this problem after upgrading to 2.6.0 from 2.5.something.
All of a sudden it wouldn't complete a backup run and I was getting
messages from cron about the planner segfaulting. I culled some
items from my disklist, and all of a sudden it starting working
again. After a little experimenting, I've come to the conclusion
that it's happening whenever a backup estimate generates a backup
size that's bigger than the current tape size. The debug logs don't
help, they just end after closing a connection for an estimate. I
do not currently have tape spanning enabled, although it will
probably be something to try soon.
Anyone else seen this or have a fix? I havn't had a chance to look
into the source yet, figured I'd ask here before I started poking
around at something I wasn't familiar with :)
Thanks!
-Darrell
Index: server-src/planner.c
===================================================================
--- server-src/planner.c (revision 11038)
+++ server-src/planner.c (working copy)
@@ -2664,7 +2664,7 @@
}
strappend(errstr, "]");
qerrstr = quote_string(errstr);
- vstrextend(&bi->errstr, " ", qerrstr);
+ vstrextend(&bi->errstr, " ", qerrstr, NULL);
amfree(errstr);
amfree(qerrstr);
arglist_end(argp);
|
