On Thu, Jul 15, 2010 at 12:23 PM, Pavel Ivanov wrote:
>> I don't think so. Just like the older SQLite journal system, it's important
>> that the WAL files survive through a crash.
>
> I believe WAL file is not a problem here (despite some confusing macro
> name that Matthew
> I don't think so. Just like the older SQLite journal system, it's important
> that the WAL files survive through a crash.
I believe WAL file is not a problem here (despite some confusing macro
name that Matthew proposed). The problem is SHM file which don't have
to survive - SQLite rebuilds
On 15 Jul 2010, at 4:52pm, Matthew L. Creech wrote:
> This exists in many Linux systems as "/dev/shm", or even "/tmp" would
> work fine for a lot of users.
I don't think so. Just like the older SQLite journal system, it's important
that the WAL files survive through a crash. SQLite finds the
So if I'm reading the documentation correctly:
The wal-index is in shared memory, and so technically it does not have
to have a name in the host computer filesystem. Custom VFS
implementations are free to implement shared memory in any way they
see fit, but the default unix and windows
>
> > In testing the latest SQLite snapshot with WAL enabled, it seems that
> > there's no way to use a database in a read-only location.
> >
>
> Documentation on the developers' current view of this issue can be found
> here:
>
>
>
In my opinion it's ok, WAL already has special conditions on
On Fri, Jul 9, 2010 at 3:21 PM, Matthew L. Creech wrote:
> In testing the latest SQLite snapshot with WAL enabled, it seems that
> there's no way to use a database in a read-only location.
>
Documentation on the developers' current view of this issue can be found
here:
In testing the latest SQLite snapshot with WAL enabled, it seems that
there's no way to use a database in a read-only location. For
example, let's say I've created a database as root, then closed it
(cleanly):
$ ls -l /flash/alarms.db*
-rw-r--r--1 root root 36864 Jan 1 00:14
7 matches
Mail list logo