http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13431 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |ASSIGNED CC| |chris@bigballofwax.co.nz --- Comment #14 from Chris Cormack <chris@bigballofwax.co.nz> --- (In reply to Jacek Ablewicz from comment #13)
Not sure how proceed with this one.. I have to admit removing fastmmap caching completely is kinda tempting, but OTOH it's not too hard to imagine some setups where such caching system would be quite beneficial performace-wise. What if we:
1) do not load nor intialize the Cache::FastMmap module, unless such caching system is explicitly requested by the user (CACHING_SYSTEM=fastmmap_cache) 2) also do not load it when $ENV{GATEWAY_INTERFACE} is not defined 3) include _both_ the UID and the database name in the /tmp sharemap file name
That way it: - would still be a trival patch, - this feature will remain available for the people who really want/need it - and (unless I'm very much mistaken) it should cover almost 100% of the problematic cases (?).
That is a good start, and couple it with the moving the cache conf back to koha-conf.xml and out of env variables (bug 11921) and we would have a less error prone and less confusing set up. But doing a patch like you suggest, will fix this bug, and then 11921 can follow on -- You are receiving this mail because: You are watching all bug changes.