database disk image is malformed

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

database disk image is malformed

Jukka Marin
Dear List,

I'm developing software which keeps parameters and real-time data in
SQLite databases on a x86_64/linux system.  I am getting "database
disk image is malformed" errors from SQLite when using select.  Some
select operations succeed, some fail.  This happens on multiple systems.

I would like to know if I'm doing something that is known not to work
with SQLite.  Background information:

The software runs on a xen virtual machine.  The database files are
on a separate disk (actually, a separate partition of the host linux)
which is directly mounted on the virtual machine (not using NFS)
and uses ext4 filesystem.  The whole system runs off a single SSD disk.

SQLite version is 3.28.0 and it is currently built and statically
linked against the application binary.

The databases are originally created by a script and the sqlite3
command.  "pragma journal_mode=wal;" is set for all databases.

The software consists of multiple processes.  The main process opens
the databases and then forks the other processes which can then perform
database operations using the already opened databases.  No locking is
done in the processes, they rely on the SQLite internal mechanisms.
sqlite3_busy_timeout is set to 2500 for all databases.

The processes mostly read (select) data from the databases, but also
occasionally add new rows or update existing rows.


Is this system with multiple processes accessing the databases
safe with SQLite?  If it is, does anyone have ideas of what could
be corrupting the database files?

These systems are running 24/7, but of course, it _may_ be possible
that someone has disconnected the power supply without shutting down
the system first and causing errors in the database files.

Is there something I could do to (try to) prevent database corruption
if power is lost?  (In software - a UPS is a hardware solution, of
course).

If the database is corrupted, is there any way of recovering it?
Maybe I should use sqlite3 to dump and recreate the database (of
course, some or all of the data might get lost)?

Experienced SQLite users, please share your ideas - thank you! :-)

  Jukka Marin
  (a beginner with SQLite)
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Shawn Wagner
This line stood out:

> The main process opens the databases and then forks the other processes
which can then perform database operations using the already opened
databases.

From
https://sqlite.org/howtocorrupt.html#_carrying_an_open_database_connection_across_a_fork_
:

> Do not open an SQLite database connection, then fork(), then try to use
that database connection in the child process. All kinds of locking
problems will result and you can easily end up with a corrupt database.
SQLite is not designed to support that kind of behavior. Any database
connection that is used in a child process must be opened in the child
process, not inherited from the parent.

In this kind of situation, I usually use pthread_atfork() callbacks to
automate closing databases and then re-opening them in the parent and child.


On Thu, Nov 7, 2019 at 9:18 AM Jukka Marin <[hidden email]> wrote:

> Dear List,
>
> I'm developing software which keeps parameters and real-time data in
> SQLite databases on a x86_64/linux system.  I am getting "database
> disk image is malformed" errors from SQLite when using select.  Some
> select operations succeed, some fail.  This happens on multiple systems.
>
> I would like to know if I'm doing something that is known not to work
> with SQLite.  Background information:
>
> The software runs on a xen virtual machine.  The database files are
> on a separate disk (actually, a separate partition of the host linux)
> which is directly mounted on the virtual machine (not using NFS)
> and uses ext4 filesystem.  The whole system runs off a single SSD disk.
>
> SQLite version is 3.28.0 and it is currently built and statically
> linked against the application binary.
>
> The databases are originally created by a script and the sqlite3
> command.  "pragma journal_mode=wal;" is set for all databases.
>
> The software consists of multiple processes.  The main process opens
> the databases and then forks the other processes which can then perform
> database operations using the already opened databases.  No locking is
> done in the processes, they rely on the SQLite internal mechanisms.
> sqlite3_busy_timeout is set to 2500 for all databases.
>
> The processes mostly read (select) data from the databases, but also
> occasionally add new rows or update existing rows.
>
>
> Is this system with multiple processes accessing the databases
> safe with SQLite?  If it is, does anyone have ideas of what could
> be corrupting the database files?
>
> These systems are running 24/7, but of course, it _may_ be possible
> that someone has disconnected the power supply without shutting down
> the system first and causing errors in the database files.
>
> Is there something I could do to (try to) prevent database corruption
> if power is lost?  (In software - a UPS is a hardware solution, of
> course).
>
> If the database is corrupted, is there any way of recovering it?
> Maybe I should use sqlite3 to dump and recreate the database (of
> course, some or all of the data might get lost)?
>
> Experienced SQLite users, please share your ideas - thank you! :-)
>
>   Jukka Marin
>   (a beginner with SQLite)
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Jukka Marin
On Thu, Nov 07, 2019 at 09:26:46AM -0800, Shawn Wagner wrote:

> This line stood out:
>
> > The main process opens the databases and then forks the other processes
> which can then perform database operations using the already opened
> databases.
>
> From
> https://sqlite.org/howtocorrupt.html#_carrying_an_open_database_connection_across_a_fork_
> :
>
> > Do not open an SQLite database connection, then fork(), then try to use
> that database connection in the child process. All kinds of locking
> problems will result and you can easily end up with a corrupt database.
> SQLite is not designed to support that kind of behavior. Any database
> connection that is used in a child process must be opened in the child
> process, not inherited from the parent.
>
> In this kind of situation, I usually use pthread_atfork() callbacks to
> automate closing databases and then re-opening them in the parent and child.

Okay, thanks!  I suspected it could be something like this, but couldn't
find anything in the SQLite docs.

I'll change my code and see what happens :-)

Thanks again for the quick reply!

  Jukka Marin
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Jukka Marin
On Fri, Nov 08, 2019 at 09:57:25AM +0200, Jukka Marin wrote:

> On Thu, Nov 07, 2019 at 09:26:46AM -0800, Shawn Wagner wrote:
> > This line stood out:
> >
> > > The main process opens the databases and then forks the other processes
> > which can then perform database operations using the already opened
> > databases.
> >
> > From
> > https://sqlite.org/howtocorrupt.html#_carrying_an_open_database_connection_across_a_fork_
> > :
> >
> > > Do not open an SQLite database connection, then fork(), then try to use
> > that database connection in the child process. All kinds of locking
> > problems will result and you can easily end up with a corrupt database.
> > SQLite is not designed to support that kind of behavior. Any database
> > connection that is used in a child process must be opened in the child
> > process, not inherited from the parent.
> >
> > In this kind of situation, I usually use pthread_atfork() callbacks to
> > automate closing databases and then re-opening them in the parent and child.
>
> Okay, thanks!  I suspected it could be something like this, but couldn't
> find anything in the SQLite docs.

In some situations, my main process will have the databases opened before
it needs to fork a new child (this happens only if a child dies and
has to be restarted).  If the child process immediately closes its copies
of the databases and then reopens them, will it be safe?

Or does the main process need to close all databases, then fork, then
reopen the databases?

Thanks again!

  Jukka Marin
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Simon Slavin-3
On 11 Nov 2019, at 1:42pm, Jukka Marin <[hidden email]> wrote:

> Or does the main process need to close all databases, then fork, then
> reopen the databases?

Which processes access the databases ?  The main process ?  Its children ?  Are they all using the same connection ?  Are they all trying to use the same connection at the same time ?
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Jukka Marin
On Mon, Nov 11, 2019 at 05:03:25PM +0000, Simon Slavin wrote:
> On 11 Nov 2019, at 1:42pm, Jukka Marin <[hidden email]> wrote:
>
> > Or does the main process need to close all databases, then fork, then
> > reopen the databases?
>
> Which processes access the databases ?  The main process ?  Its children ?  Are they all using the same connection ?
>  Are they all trying to use the same connection at the same time ?

All processes access the databases.  No, I changed the code so that
every process opens the databases separately, so they use their own
connections (at random times, so probably simultaneously).

The main process first opens the databases and checks that their
version matches that of the software and if not, the databases are
closed and initialized by running a script.

After closing the databases, main process forks the children and
all processes (including main process) open the databases and use
their own connections.

What I was trying to ask was this:  If any of the children dies
(a bug in the code), main process will restart the child.  At
this point, the main process has the databases open, so the new
child receives the connections as well.  What should I do now?
Should the child close the databases before opening them again?
Will this close the databases for the main process as well?

(One way is to stop using the databases in the main process, so
they are not passed to children, but this would be a major change
in the code.)

  -jm
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Shawn Wagner
In reply to this post by Jukka Marin
Doing the latter - closing everything, forking, re-opening - is always
going to be safe. Or if the parent isn't going to use the connection, just
don't open the database until you're in the child after forking.

On Mon, Nov 11, 2019 at 8:08 AM Jukka Marin <[hidden email]> wrote:

> On Fri, Nov 08, 2019 at 09:57:25AM +0200, Jukka Marin wrote:
> > On Thu, Nov 07, 2019 at 09:26:46AM -0800, Shawn Wagner wrote:
> > > This line stood out:
> > >
> > > > The main process opens the databases and then forks the other
> processes
> > > which can then perform database operations using the already opened
> > > databases.
> > >
> > > From
> > >
> https://sqlite.org/howtocorrupt.html#_carrying_an_open_database_connection_across_a_fork_
> > > :
> > >
> > > > Do not open an SQLite database connection, then fork(), then try to
> use
> > > that database connection in the child process. All kinds of locking
> > > problems will result and you can easily end up with a corrupt database.
> > > SQLite is not designed to support that kind of behavior. Any database
> > > connection that is used in a child process must be opened in the child
> > > process, not inherited from the parent.
> > >
> > > In this kind of situation, I usually use pthread_atfork() callbacks to
> > > automate closing databases and then re-opening them in the parent and
> child.
> >
> > Okay, thanks!  I suspected it could be something like this, but couldn't
> > find anything in the SQLite docs.
>
> In some situations, my main process will have the databases opened before
> it needs to fork a new child (this happens only if a child dies and
> has to be restarted).  If the child process immediately closes its copies
> of the databases and then reopens them, will it be safe?
>
> Or does the main process need to close all databases, then fork, then
> reopen the databases?
>
> Thanks again!
>
>   Jukka Marin
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Simon Slavin-3
In reply to this post by Jukka Marin
On 11 Nov 2019, at 5:13pm, Jukka Marin <[hidden email]> wrote:

> The main process first opens the databases and checks that their
> version matches that of the software and if not, the databases are
> closed and initialized by running a script.
>
> After closing the databases, main process forks the children and
> all processes (including main process) open the databases and use
> their own connections.
>
> What I was trying to ask was this:  If any of the children dies
> (a bug in the code), main process will restart the child.  At
> this point, the main process has the databases open, so the new
> child receives the connections as well.  What should I do now?

Okay, that gives us enough information to work with.

The conservative way to do it is to have the main process close the connection before forking and open it again.  Then, of course, the child processes make their own connections.

But I don't think that's necessary.  A child process can have access to the main process' database connection but ignore it.  So I think the main process can fork without closing its connection.  Then each child can never use that one but instead make its own.

Of course, every one of these connections needs to set a timeout.  And every call to the SQLite3 library needs to check its result code and make sure it is getting SQLITE_OK (or, for queries, SQLITE_DONE etc.).

> Should the child close the databases before opening them again?
> Will this close the databases for the main process as well?

As you suspected, closing the connection releases both memory structures and file handles.  Anything that tries to use that connection will then fail because it has no idea what it's talking to.

What puzzles me is this: you're getting "database malformed" and nothing you've described justifies this.  Assuming that this isn't just one old database which is genuinely corrupt, but that you are using a fresh uncorrupt database each time, you seem to have a genuine bug in your code.

This happens mostly because something is stomping on the memory assigned to a connection.  In your case, this probably means something is stomping on the memory assigned to one of the child processes.

So, first write yourself a quick script to use the shell tool to check the database for corruption.  Then run that, even while your program is running, and see if you can figure out whether your database really is corrupt or whether your program is getting spurious error messages.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Jukka Marin
On Mon, Nov 11, 2019 at 05:37:37PM +0000, Simon Slavin wrote:

> On 11 Nov 2019, at 5:13pm, Jukka Marin <[hidden email]> wrote:
>
> > The main process first opens the databases and checks that their
> > version matches that of the software and if not, the databases are
> > closed and initialized by running a script.
> >
> > After closing the databases, main process forks the children and
> > all processes (including main process) open the databases and use
> > their own connections.
> >
> > What I was trying to ask was this:  If any of the children dies
> > (a bug in the code), main process will restart the child.  At
> > this point, the main process has the databases open, so the new
> > child receives the connections as well.  What should I do now?
>
> Okay, that gives us enough information to work with.
>
> The conservative way to do it is to have the main process close the connection before forking and open it again.  Then, of course, the child processes make their own connections.
>
> But I don't think that's necessary.  A child process can have access to the main process' database connection but ignore it.  So I think the main process can fork without closing its connection.  Then each child can never use that one but instead make its own.

Okay, that's what I was hoping for.

> Of course, every one of these connections needs to set a timeout.  And every call to the SQLite3 library needs to check its result code and make sure it is getting SQLITE_OK (or, for queries, SQLITE_DONE etc.).

Yes, I'm doing all this,

> > Should the child close the databases before opening them again?
> > Will this close the databases for the main process as well?
>
> As you suspected, closing the connection releases both memory structures and file handles.  Anything that tries to use that connection will then fail because it has no idea what it's talking to.

Ok.

> What puzzles me is this: you're getting "database malformed" and nothing you've described justifies this.  Assuming that this isn't just one old database which is genuinely corrupt, but that you are using a fresh uncorrupt database each time, you seem to have a genuine bug in your code.

That was happening before I changed my code to open the databases in
the children.  Originally, only main process opened the databases and
the children "inherited" the connections.  I was wondering if this was
okay, but I didn't see a warning in the SQLite docs, so.. I never found
the "how to corrupt your database" manual on my own ;-)

I came back to the mailing list when I noticed the above "problem" of
a child dying and needing to respawn it while the main process already
has the databases open.

So I guess it's safe now that all the children open the databases by
themselves.

Thanks to all who responded!

  -jm
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Andreas Kretzer
In reply to this post by Simon Slavin-3
Just to make sure, you didn't oversee that (like I was ...):
Daemonizing a process is also a fork() - and this invalidates
your connection!

I used the daemon() function in my program (together with a
few other processes) that used a DB connection. I opened
this connection _before_ I called daemon() and everything seemed
right. But as soon, as the other processes terminated, the lock
and WAL files went away, and everything I did with the DB didn't
reach the actual files. After that, the DB image was damaged.

Andreas

Am 11.11.2019 um 18:37 schrieb Simon Slavin:

> On 11 Nov 2019, at 5:13pm, Jukka Marin <[hidden email]> wrote:
>
>> The main process first opens the databases and checks that their
>> version matches that of the software and if not, the databases are
>> closed and initialized by running a script.
>>
>> After closing the databases, main process forks the children and
>> all processes (including main process) open the databases and use
>> their own connections.
>>
>> What I was trying to ask was this:  If any of the children dies
>> (a bug in the code), main process will restart the child.  At
>> this point, the main process has the databases open, so the new
>> child receives the connections as well.  What should I do now?
> Okay, that gives us enough information to work with.
>
> The conservative way to do it is to have the main process close the connection before forking and open it again.  Then, of course, the child processes make their own connections.
>
> But I don't think that's necessary.  A child process can have access to the main process' database connection but ignore it.  So I think the main process can fork without closing its connection.  Then each child can never use that one but instead make its own.
>
> Of course, every one of these connections needs to set a timeout.  And every call to the SQLite3 library needs to check its result code and make sure it is getting SQLITE_OK (or, for queries, SQLITE_DONE etc.).
>
>> Should the child close the databases before opening them again?
>> Will this close the databases for the main process as well?
> As you suspected, closing the connection releases both memory structures and file handles.  Anything that tries to use that connection will then fail because it has no idea what it's talking to.
>
> What puzzles me is this: you're getting "database malformed" and nothing you've described justifies this.  Assuming that this isn't just one old database which is genuinely corrupt, but that you are using a fresh uncorrupt database each time, you seem to have a genuine bug in your code.
>
> This happens mostly because something is stomping on the memory assigned to a connection.  In your case, this probably means something is stomping on the memory assigned to one of the child processes.
>
> So, first write yourself a quick script to use the shell tool to check the database for corruption.  Then run that, even while your program is running, and see if you can figure out whether your database really is corrupt or whether your program is getting spurious error messages.
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


--

Mit freundlichen Grüßen
Andreas Kretzer

ETB Electronic Team
Beratungs- und Vertriebs GmbH

Berliner Straße 8a
15537 Erkner

FON   +49 3362 889349-12
FAX   +49 3362 889349-23

email: [hidden email]

AG Potsdam HRB 16532; Sitz der Gesellschaft: Am Mellensee
Geschäftsführer: Wolfgang A. Runge, Marco Runge, Jürgen Gentzsch


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Graham Holden
In reply to this post by Jukka Marin
I've been having problems with my email system... I don't think
earlier attempts at sending have made it to the list, but if they
did, apologies for any duplication...

Monday, November 11, 2019, 5:46:05 PM, Jukka Marin <[hidden email]> wrote:

>> On 11 Nov 2019, at 5:13pm, Jukka Marin <[hidden email]> wrote:
>>
>> > The main process first opens the databases and checks that their
>> > version matches that of the software and if not, the databases are
>> > closed and initialized by running a script.
>> >
>> > After closing the databases, main process forks the children and
>> > all processes (including main process) open the databases and use
>> > their own connections.
>> >
>> > What I was trying to ask was this:  If any of the children dies
>> > (a bug in the code), main process will restart the child.  At
>> > this point, the main process has the databases open, so the new
>> > child receives the connections as well.  What should I do now?
>>

This isn't from personal experience, but (possibly misremembered)
snippets from this list and (possibly incorrect) deductions from
them...

The problem (or, perhaps, "a" problem) with passing SQLite connections
across fork() is, I think, how Linux?/POSIX? deals with file-locks on
the underlying file-handle. IIRC, if both parent/child process share a
file-handle, and one of them closes that file, then ALL file-level
locks (which is what SQLite uses) on that handle are released: not
just the ones created by the terminating process.

What I *think* this may mean is that re-spawned children will inhereit
the open file-handle of the SQLite connection opened by the parent
after it initially fired all child processes. Even if the (re-spawned)
child never make use of that connection or the file-handle, when it
next dies (either a natural death or another unexpected termination),
then the OS will close the inherited file-handle and release all
file-locks on it (that would have been created by the parent process).

At this point, the parent process will THINK it has appropriate
file-locks and that it is safe to access the database file, but to all
the other (child) processes, it does not appear to have any locks, and
they too may try to access the database file. And that way, madness
lies!

I *suspect* Simon's "The conservative way to do it" (close the
connection/file-handle around re-spawns) may be more necessary than
originally thought. (Alternatively, perhaps, have whatever database
access the parent is doing happen in another child process, and have
the parent "just" monitoring processes and re-spawning as needed).

Of course, I may be wrong, or the "releasing all locks" may only apply
in some circumstances... hopefully someone with more direct experience
can confirm or deny.

Graham


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Simon Slavin-3
On 15 Nov 2019, at 8:03am, Graham Holden <[hidden email]> wrote:

> What I *think* this may mean is that re-spawned children will inhereit
> the open file-handle of the SQLite connection opened by the parent
> after it initially fired all child processes.

That's not a problem.

> Even if the (re-spawned)
> child never make use of that connection or the file-handle, when it
> next dies (either a natural death or another unexpected termination),
> then the OS will close the inherited file-handle and release all
> file-locks on it

That's a huge problem.  In which case you're right: the parent process should close SQLite connections before it forks.

Is that really how Unix works ?  How annoying.  Seems a strange design-choice, but it wouldn't be the only one.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Rowan Worth-2
In reply to this post by Graham Holden
On Fri, 15 Nov 2019 at 16:10, Graham Holden <[hidden email]> wrote:

> I've been having problems with my email system... I don't think
> earlier attempts at sending have made it to the list, but if they
> did, apologies for any duplication...
>
> Monday, November 11, 2019, 5:46:05 PM, Jukka Marin <[hidden email]>
> wrote:
>
> >> On 11 Nov 2019, at 5:13pm, Jukka Marin <[hidden email]> wrote:
> >>
> >> > The main process first opens the databases and checks that their
> >> > version matches that of the software and if not, the databases are
> >> > closed and initialized by running a script.
> >> >
> >> > After closing the databases, main process forks the children and
> >> > all processes (including main process) open the databases and use
> >> > their own connections.
> >> >
> >> > What I was trying to ask was this:  If any of the children dies
> >> > (a bug in the code), main process will restart the child.  At
> >> > this point, the main process has the databases open, so the new
> >> > child receives the connections as well.  What should I do now?
> >>
>
> This isn't from personal experience, but (possibly misremembered)
> snippets from this list and (possibly incorrect) deductions from
> them...
>
> The problem (or, perhaps, "a" problem) with passing SQLite connections
> across fork() is, I think, how Linux?/POSIX? deals with file-locks on
> the underlying file-handle. IIRC, if both parent/child process share a
> file-handle, and one of them closes that file, then ALL file-level
> locks (which is what SQLite uses) on that handle are released: not
> just the ones created by the terminating process.
>

The mechanism you're thinking of exists, but only between threads of the
same process. It's also described in the "how to corrupt an sqlite database
file" writeup, section 2.2:

https://sqlite.org/howtocorrupt.html#_posix_advisory_locks_canceled_by_a_separate_thread_doing_close_

fork creates separate processes, so it shouldn't be impacted by that
mechanism. But there's an easily identified problem: posix locks are not
inherited by a fork()ed child, and sqlite keeps track (in-memory) of what
locks it has acquired. So after a fork() the child will inherit sqlite's
internal idea of what locks are held, but none of the actual locks, making
it instantly out of sync with reality if any locks were held.

-Rowan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: database disk image is malformed

Peter da Silva-2
I have been bitten by this a couple of times, so now I'm super-conservative
about how I deal with this.

What I do is have any parent database setup done by having the parent spawn
a child process to do the actual database work, and return any data the
parent needs in the status or (if more than a success status is needed)
through a pipe.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users