[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous m
From: |
Ludovic Courtès |
Subject: |
bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol |
Date: |
Fri, 10 Jul 2020 14:34:28 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hi,
Jan Nieuwenhuizen <janneke@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’.
- bug#42151: [PATCH 1/3] gnu: Add sqlite/hurd with locking fix., (continued)
- bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol, Jan Nieuwenhuizen, 2020/07/01
- bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol, Ludovic Courtès, 2020/07/02
- bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol, Jan Nieuwenhuizen, 2020/07/03
- bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol, Ludovic Courtès, 2020/07/03
- bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol, Jan Nieuwenhuizen, 2020/07/03
- bug#42151: [PATCH 4/3] database: Do not use journal_model=WAL for the Hurd., Jan Nieuwenhuizen, 2020/07/04
- bug#42151: [PATCH 4/3] database: Do not use journal_model=WAL for the Hurd., Jan Nieuwenhuizen, 2020/07/07
- bug#42151: [PATCH 4/3] database: Do not use journal_model=WAL for the Hurd., Ludovic Courtès, 2020/07/10
- bug#42151: [PATCH 4/3] database: Do not use journal_model=WAL for the Hurd., Jan Nieuwenhuizen, 2020/07/10
- bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol,
Ludovic Courtès <=
bug#42151: [PATCH v2 1/4] gnu: Add sqlite/hurd with locking fix., Jan (janneke) Nieuwenhuizen, 2020/07/10
bug#42151: [PATCH v3 1/2] gnu: sqlite: Add locking-mode fix for the Hurd., Jan (janneke) Nieuwenhuizen, 2020/07/10
bug#42151: [PATCH v3 1/2] gnu: sqlite: Add locking-mode fix for the Hurd., Ludovic Courtès, 2020/07/11