This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Alexander Chemeris alexander.chemeris at gmail.comOn Fri, Feb 21, 2014 at 3:52 AM, Peter Stuge <peter at stuge.se> wrote: > Alexey Shamrin wrote: > > > > WAL journaling mode is persistent; it stays in effect after closing and > > > > reopening the database. WAL mode database requires SQLite >= 3.7.0. > > > Think about this some more. It's not enough to state dependencies in > > > a commit message, you need to put them in the build system. A patch > > > to do this will need to touch configure.ac, and I think it would be > > > wise to make the requirement optional. > > > > Is it really needed in this particular case? OpenBSC would continue > > working with SQLite < 3.7.0. It would just ignore `journal_mode = WAL` > > and keep using `DELETE` mode. The only thing that won't work is > > downgrading from newer SQLite to older while keeping the same database > > file. Older SQLite would refuse to open the database that was once > > opened in WAL mode. The file could be downgraded by changing > > journal_mode on it. But only newer SQLite could do it. Do you think > > something must be done about it? > > Thanks for explaining in more detail! I do think something more needs > to be done but I'm no longer so sure what I'd prefer.. > > I think it would be good to have a build-time (configure) option to > explicitly enable WAL journalling and thus also require the newer > SQLite version. I don't think we need configure check - see my explanation below. > I also think that a version of OpenBSC built without WAL enabled > has to be able to recognize databases created by OpenBSC built *with* > WAL enabled, and tell the user what needs to be done to make the > database work. > > Finally, maybe the database version number should also be bumped, to > allow OpenBSC using >=3.7 to know whether a database needs WAL or not. I'm not sure about the DB version bump, as it doesn't touch DB structure. OTOH I think we should have a code which enables WAL in old DBs, and then it's reasonable to do in the section where we upgrade DBs. OTOH, an OpenBSC with SQLite < 3.7 should be able to jump onto a potential next DB revision without jumping over this "pseudo-revison". Otherwise it would be meaningless - DB version won't tell us whether we have WAL or not. After all, I think the proper way is as follows: 1. OpenBSC should try to set WAL pragma on every start, unless a --no-wal command line option is specified: 2. OpenBSC should check SQLite version on startup and if it's <3.7 - print a warning to log that WAL can't be enabled and we recommend upgrading. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru