Hi, Jan Nieuwenhuizen <jann...@gnu.org> skribis:
> Ludovic Courtès writes: > > Hi! > >>> It seems there is a compatibility bug/problem/thing with the db.sqlite >>> that we produce on GNU/Linux. While an unpatched sqlite3 on the Hurd >>> can read it, and work with it, the unpatched sqlite has locking >>> problems. I found a workaround, though: dumping and loading the >>> database file. > > [..] > >>> So...about the compatibility problem. I tried to diff the db.sqlite-orig >>> db.sqlite-init binary files: they look completely different. Not sure >>> how to handle this workaround, maybe we can insert a two system* calls >>> somewhere when building the disk image? >> >> Weird, weird! >> >> Could you compare ‘db.dump’ created on GNU/Hurd with ‘db.dump’ created >> from the same ‘sqlite3 -init’ command on GNU/Linux? > > Yeah, they are identical. The initial dump can only be created atm on > GNU/Linux; the dump can be loaded (obviously) anywhere like so > >>> $ sqlite3 -init db.dump db.sqlite-init .quit > > and the resulting initial db.sqlite is the same. Guess we can do that > by hand for now... > >> (Perhaps loading the dump reorders entries or something.) > > Yes, "or something" certainly! :) I have no clue... Sorry for catching up days later but… did disabling WAL mode fix this discrepancy? IOW, without WAL mode, is the file produced on GNU/Linux bit-identical to that produced on GNU/Hurd? > If/when we decide to pinpoint this bug, what could be a first step? Who > is creating the database right now, is that the C++ daemon or > guile-sqlite3. IWBN to have that code create/save a smaller version and > see when reading fails. As you found out it’s created by (guix store database) in this case. Thanks, Ludo’.
