segfaults with decached

I'm sorry for such a burst of posts! I don't know if this is a unique problem, but I am getting a segfault if I have any of the wl_ options set to dbcached. They work fine if set to db. Has anyone run into a similar problem?

Forums: 

Do the tables exist? Otherwise run gps once but set mode to init in the config file to create the tables.

Yes, the tables exist. If the table is empty, GPS doesn't segfault if dbcached is set -- it only occurs if the table has entries in it. If I use db instead, the table is read normally. I will try this on a second system -- I had some problems getting GPS to compile -- is it possible that an error occurred somehow during compilation? Otherwise it seems to work fine...

Jeff

Hmm, reading some of the other posts, I am wondering how much dbcache actually matters in my situation anyway. The db is only cached if a new query comes in before the GPS process is killed, right? That's a window of a minute or so, right? I don't have a lot of traffic so most of the time, it would be a new query.

I keep going back and forth between GPS and Gld. Gld seems a bit faster (which I think is natural since it runs as a daemon), but the "reverse" feature of GPS is very appealing.

Jeff

re compilation.

I installed gps on a fresh system today and have to say: It's not exactly simple.

I think I'll post a mini-howto here sometime soon.

One otehr thing I noticed is that I get segfaults when using the stock libdbd-mysql package in debian. But when I rebuild teh package from source gps runs fine. Is that maybe what you are observing?

Re gld -- I have looked at it. Written in C and certainly much faster than gps. There is always a tradeoff between "features" (bugs) and performance. But I dont think that has to do with the fact it's a daemon. In a way my thinking was that connecting from one daemon (gld) to another daemon (mysql) is a bit redundant.

I noticed a new version of libdb-mysql came down today, and the seg faults appear to have gone away. I think... fingers crossed.