Gnucash in "MySQL server has gone away" loop

[John Ralls]

On Oct 4, 2011, at 5:16 AM, Christopher X. Candreva wrote:

> On Mon, 3 Oct 2011, John Ralls wrote:
> 
>> Interesting. 36 seconds later, same as the time between the query and the 
>> "reconnecting" loop on the F15.
> 
>> Googling the error, it appears that perhaps we're being too aggressive in 
>> batching the slots query, so that the response is bigger than can be 
>> accommodated without tuning the database (which the stacktrace crowd says 
>> must be done at both ends). Odd that the newer version croaks silently.
> 
>> I think that's telling you that you can't safely use the db, even on the 
>> F14, since it's dropping a bunch of your transactions after the error.
> 
> I switched to the file format as soon as I was able to load data at all. I 
> was afraid of that when I saw the error last night. I'll have to do some 
> spot checking tonight to see what may be missing.
> 
>> How big is the db?
> 
> Checking from rom phpMyAdmin, 21k rows in slots, 30k in splits, 15k in 
> transactions. I had imported Quicken data going back to -- (checks oldest 
> account) -- 1993 ! Wow, didn't realize it had data that old !
> 

It turns out there's a MySql bug [1] on the 2006--server went away error, and it has to do with trying to send to the server
a query that's too big. I had been thinking that the problem was in the other direction, that the *responese* was too big
and the client was choking. That bug was supposed to have been fixed in 5.0 -- to do what you're experiencing on 5.1. Looks like they've got a regression. You might want to report that.

So, try jacking up the max_allowed_packet on the server side (apparently in /etc/my.cnf) and see if that makes a difference.

I also had a look at the error-handling code. We just try to reconnect on a 2006, and the message we emit doesn't report the error message... so I think that the server is responding to our connection attempts with another 2006. We could close the connection and re-initialize, but that's really not going to help much with the actual error -- we'll still get another 2006 as soon as we retry whatever query caused the problem, so I guess bailing with a helpful error message is the best we can do. If jacking up the max_allowed_packet works, then we can make that a recommendation in the error message.


Regards,
John Ralls

[1] http://bugs.mysql.com/bug.php?id=1011