[sqlite] IS a SQLite db of small size as good as reliable cache?
GB wrote: > So where have you got this wisdom from? It's just plain Bullshit! > > Just as most cache managers do, Windows cache manager uses some sort of LRU > caching scheme. So all data once read from file is kept in memory until either > some memory pressure occurs or it is simply pushed out by newer data. No. Windows will toss clean pages out even in the total absence of memory pressure. It is moronic, but true. You can repeat the steps I outlined for yourself and see. https://groups.google.com/d/msg/comp.os.ms-windows.nt.misc/449tdNYPoX0/it4cx8Gvv2AJ > Actually, from what I've experienced, I'd recommend to size sqlite's memory to > fit for your largest transactions and leave most of the caching to the OS. > > And yes, unlike in many *NIX implementations, Windows' FlushFileBuffers() call > DOES issue according write commands to the hardware, so setting PRAGMA > synchronous ON/OFF makes a big difference in write performance on Windows > systems. > > Howard Chu schrieb am 30.01.2016 um 23:23: >> dpb wrote: >>> Dear Community, >>> >>> Assuming that SQLite would arrange the database table contents on page >>> boundary and >>> >>> 1) if db is small let us say maximum 5MB, >>> >>> 2 further if such a db is part of windows service / application running >>> continuously then may be pages will remain in the memory under normal >>> conditions. >>> >>> Q1) Operating System like Windows would cache the series of pages, is this >>> behavior not almost same as that of Cache? >> The Windows cache manager is quite aggressive at evicting cached pages from >> RAM. It used to be tunable back in Win2000, but none of those tuning knobs >> survived past WinXP. Generally, if you access some data, leave it for more >> than 5-10 seconds, don't expect to be able to reference it again without >> incurring a hard page fault. >> >> Note that the cache eviction runs quite frequently - once every 5 seconds or >> so, and evicts pages regardless of whether there's any memory pressure in the >> system. It's quite possibly the stupidest cache manager ever written. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
[sqlite] IS a SQLite db of small size as good as reliable cache?
On Wed, 3 Feb 2016 23:25:33 +0100 GB wrote: > So where have you got this wisdom from? It's just plain Bullshit! > > Just as most cache managers do, Windows cache manager uses some sort of > LRU caching scheme. So all data once read from file is kept in memory > until either some memory pressure occurs or it is simply pushed out by > newer data. Actually, from what I've experienced, I'd recommend to size > sqlite's memory to fit for your largest transactions and leave most of > the caching to the OS. > > And yes, unlike in many *NIX implementations, Windows' > FlushFileBuffers() call DOES issue according write commands to the > hardware, so setting PRAGMA synchronous ON/OFF makes a big difference in > write performance on Windows systems. > I agree there are too much incorrect statements about Windows's behaviour, however, on a Linux system, I could check (just for testing it) `PRAGMA synchronous ON/OFF` makes a difference with at least small transactions, while it's less perceptible with big transactions (small and big is vague, that's just to keep the wording simple). I guess on Windows too, when the transactions are big, using synchronous mode or not, will make less difference than with small transactions, understandably. -- Yannick Duch?ne
[sqlite] IS a SQLite db of small size as good as reliable cache?
So where have you got this wisdom from? It's just plain Bullshit! Just as most cache managers do, Windows cache manager uses some sort of LRU caching scheme. So all data once read from file is kept in memory until either some memory pressure occurs or it is simply pushed out by newer data. Actually, from what I've experienced, I'd recommend to size sqlite's memory to fit for your largest transactions and leave most of the caching to the OS. And yes, unlike in many *NIX implementations, Windows' FlushFileBuffers() call DOES issue according write commands to the hardware, so setting PRAGMA synchronous ON/OFF makes a big difference in write performance on Windows systems. Howard Chu schrieb am 30.01.2016 um 23:23: > dpb wrote: >> Dear Community, >> >> Assuming that SQLite would arrange the database table contents on page >> boundary and >> >> 1) if db is small let us say maximum 5MB, >> >> 2 further if such a db is part of windows service / application running >> continuously then may be pages will remain in the memory under normal >> conditions. >> >> Q1) Operating System like Windows would cache the series of pages, is this >> behavior not almost same as that of Cache? > The Windows cache manager is quite aggressive at evicting cached pages from > RAM. It used to be tunable back in Win2000, but none of those tuning knobs > survived past WinXP. Generally, if you access some data, leave it for more > than 5-10 seconds, don't expect to be able to reference it again without > incurring a hard page fault. > > Note that the cache eviction runs quite frequently - once every 5 seconds or > so, and evicts pages regardless of whether there's any memory pressure in the > system. It's quite possibly the stupidest cache manager ever written. >
[sqlite] Segment fault when running a query
Hi,
I've a reproduceable error in my code, running a simple SQL question
gives me a segment fault. Running the program i gdb and doing backtrace
gives me this:
(gdb) backtrace
#0 malloc_consolidate (av=av at entry=0x776be620 ) at
malloc.c:4149
#1 0x77394ee8 in _int_malloc (av=0x776be620 ,
bytes=3224) at malloc.c:3423
#2 0x77397070 in __GI___libc_malloc (bytes=3224) at
malloc.c:2891
#3 0x77b53e77 in ?? () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#4 0x77b2b12f in ?? () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#5 0x77b86cee in ?? () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#6 0x77b87442 in ?? () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#7 0x77b877b7 in ?? () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#8 0x77b87a66 in sqlite3_prepare_v2 () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#9 0x77b87b21 in sqlite3_exec () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#10 0x004079a1 in list_event (v=0x622d20, account_id=41,
nbr_of_results=10) at event.c:223
#11 0x0040b5a8 in load_account (account_id=41, v=0x622d20) at
account.c:603
#12 0x00401baa in tload_account () at t/test.c:201
#13 0x00402017 in taccount () at t/test.c:271
#14 0x0040369e in all_tests () at t/test.c:668
#15 0x0040374d in main (argc=1, argv=0x7fffe4a8) at
t/test.c:683
The SQL in question is: SELECT id, date, text FROM events WHERE
account_id=41 ORDER BY date DESC LIMIT 10
and it works fine running in the sqlite3 program (the query program that
comes with sqlite3).
Now the code above in list_event() has been working before but broke
after a minor change that shouldn't effect sqlite3. I might have done
that, however I don't expect this behaviour from sqlite3.
The code that gives that error could be seen here:
221 if ( v == NULL)
222 flog("view is NULL\n\n");
223 rc = sqlite3_exec(db, "SELECT id, date, text FROM events
WHERE account_id=1 ORDER BY date DESC LIMIT 10" , NULL, NULL, );
224 flog("query done\n");
225
226 if (rc != SQLITE_OK) {
227 flog("ERROR: Could not list events, SQL error:
%s\n\n%s", zErrMsg, q);
228 sqlite3_free(zErrMsg);
229 toret = -1;
230 }
The callback function is never called.
Despite any errors in my code (which I'm sure there's), why does
sqlite3 crash this way?
--
Fredrik Gustafsson
phone: +46 733-608274
e-mail: iveqy at iveqy.com
website: http://www.iveqy.com
[sqlite] Segment fault when running a query
Hi,
I've a reproduceable error in my code, running a simple SQL question
gives me a segment fault. Running the program i gdb and doing backtrace
gives me this:
(gdb) backtrace
#0 malloc_consolidate (av=av at entry=0x776be620 ) at
malloc.c:4149
#1 0x77394ee8 in _int_malloc (av=0x776be620 ,
bytes=3224) at malloc.c:3423
#2 0x77397070 in __GI___libc_malloc (bytes=3224) at malloc.c:2891
#3 0x77b53e77 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#4 0x77b2b12f in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#5 0x77b86cee in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#6 0x77b87442 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#7 0x77b877b7 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#8 0x77b87a66 in sqlite3_prepare_v2 () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#9 0x77b87b21 in sqlite3_exec () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#10 0x004079a1 in list_event (v=0x622d20, account_id=41,
nbr_of_results=10) at event.c:223
#11 0x0040b5a8 in load_account (account_id=41, v=0x622d20) at
account.c:603
#12 0x00401baa in tload_account () at t/test.c:201
#13 0x00402017 in taccount () at t/test.c:271
#14 0x0040369e in all_tests () at t/test.c:668
#15 0x0040374d in main (argc=1, argv=0x7fffe4a8) at t/test.c:683
The SQL in question is: SELECT id, date, text FROM events WHERE
account_id=41 ORDER BY date DESC LIMIT 10
and it works fine running in the sqlite3 program (the query program that
comes with sqlite3).
Now the code above in list_event() has been working before but broke
after a minor change that shouldn't effect sqlite3. I might have done
that, however I don't expect this behaviour from sqlite3.
The code that gives that error could be seen here:
221 if ( v == NULL)
222 flog("view is NULL\n\n");
223 rc = sqlite3_exec(db, "SELECT id, date, text FROM events WHERE
account_id=1 ORDER BY date DESC LIMIT 10" , NULL, NULL, );
224 flog("query done\n");
225
226 if (rc != SQLITE_OK) {
227 flog("ERROR: Could not list events, SQL error:
%s\n\n%s", zErrMsg, q);
228 sqlite3_free(zErrMsg);
229 toret = -1;
230 }
The callback function is never called.
Despite any errors in my code (which I'm sure there's), why does
sqlite3 crash this way?
--
Fredrik Gustafsson
phone: +46 733-608274
e-mail: iveqy at iveqy.com
website: http://www.iveqy.com
[sqlite] Bug: Successfully committed transaction rolled back after power failure
On Wed, 03 Feb 2016 06:30:13 -0700 "Keith Medcalf" wrote: > > Is this on windows? Any errors in the Eventlogs to the tune "Oooopsie -- > accidentally threw away your data instead of writing it to disk"? Windows > does this quite commonly under some circumstances. MicroSoft created the bug > in NT 4 and has been unable to locate or fix it since -- though there is no > problem producing an error message about 50% of the time it happens. No, that's Ubuntu Trusty 32 bits on Ext4. For an anecdote, I personally never had file system issues with Windows, the only few cases I had was with Ubuntu (especially with Btrfs which I left for this reason). > [?] > > > > Coincidence. I just had a funny incident; may be it's related. > > > > I just modified a program so that it create fours triggers in a database. > > I ran the program, then got an error from APSW (the program uses Python) > > complaining about an I/O or disk error. This frightened me a bit, but I > > though this may be due to SQLiteBrowser opened on the same DB, which I > > forget to close and I closed just after I started the program, which was > > subject to the I/O issue. I open the DB and can see only two of the four > > triggers, two missing. So I delete the DB and regenerate it three times, > > without error messages, but still two triggers missing. That's only at the > > fourth repetition the four triggers was all there. > > > > The SMART data indicates zero reallocated sectors. > > > > In the SMART utility, I noticed there is an hardware cache, which I > > disabled, in case of and thinking about ?lying devices? I remembered from > > this message. > > > > This is frightening to me, as I got an error message the first time only, > > but not the other times while something wrong seems to have happened too. > > Also, I could notice something was missing in the DB (even when generated > > without an error notification), because it was about something I was > > precisely looking at, at that moment; if it had been about some rows > > missing in any table, I would have not noticed it. > > > > Hardware failure? OS failure? Software failure? Can't tell for sure?? -- Yannick Duch?ne
[sqlite] Table entries disappearing for unknown reason.
Ok, the problem is solved. Thanks for the support.
2016-02-03 13:13 GMT-02:00 Vin?cius da Silva :
> I think I have discovered the problem. SQLiteManager::init( const string&
> dbFileName, const bool deleteDbFileFlag = true ) was deleting and
> recreating the database file for each new connection. That was probably
> corrupting SQLite state and a SQLITE_IOERR_DELETE_NOENT was correctly being
> returned at transaction ending, since the original file to write was
> replaced by another one. Some multithreaded tests are passing already. I
> will finish the tests to put the final verdict here.
>
> 2016-02-03 12:56 GMT-02:00 Vin?cius da Silva :
>
>> With a single thread and two interleaved transactions, the tests hangs in
>> what seems a deadlock.
>>
>> 2016-02-03 12:21 GMT-02:00 Clemens Ladisch :
>>
>>> Vin?cius da Silva wrote:
>>> > Using BEGIN EXCLUSIVE TRANSACTION in place of BEGIN TRANSACTION does
>>> not
>>> > change the result
>>>
>>> I meant, try executing them so that they are guaranteed to conflict,
>>> like this:
>>>
>>> db1.init("same_file");
>>> db2.init("same_file");
>>> db1.beginTransactionExclusive();
>>> db2.beginTransactionExclusive();
>>>
>>>
>>> Regards,
>>> Clemens
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users at mailinglists.sqlite.org
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>
>>
>>
>> --
>> Best Regards,
>>
>> Vin?cius da Silva ,
>> Ph. D. Student.
>> PESC - UFRJ
>>
>
>
>
> --
> Best Regards,
>
> Vin?cius da Silva ,
> Ph. D. Student.
> PESC - UFRJ
>
--
Best Regards,
Vin?cius da Silva ,
Ph. D. Student.
PESC - UFRJ
[sqlite] Table entries disappearing for unknown reason.
Vin?cius da Silva wrote:
> Using BEGIN EXCLUSIVE TRANSACTION in place of BEGIN TRANSACTION does not
> change the result
I meant, try executing them so that they are guaranteed to conflict, like this:
db1.init("same_file");
db2.init("same_file");
db1.beginTransactionExclusive();
db2.beginTransactionExclusive();
Regards,
Clemens
[sqlite] a sqlite database error
Hello, my name is Frank. Two days ago, I operated sqlite database, and got an error, I don't known what the error means, so I hope if you see the email, please respond me. Thank you very much! iPhone
[sqlite] Bug: Successfully committed transaction rolled back after power failure
> Is this on windows? The original problem was on QNX 6.5 employing a QNX6 filesystem on mNAND flash. S.M. -- Dipl.-Phys. (Univ) Stefan Meinlschmidt, Senior Software Engineer Am Wolfsmantel 46, 91058 Tennenlohe, Germany Tel: +49-8458-3332-531 stefan.meinlschmidt at esolutions.de Fax: +49-8458-3332-20-531
[sqlite] Segment fault when running a query
Hi,
I've a reproduceable error in my code, running a simple SQL question
gives me a segment fault. Running the program i gdb and doing backtrace
gives me this:
(gdb) backtrace
#0 malloc_consolidate (av=av at entry=0x776be620 ) at
malloc.c:4149
#1 0x77394ee8 in _int_malloc (av=0x776be620 ,
bytes=3224) at malloc.c:3423
#2 0x77397070 in __GI___libc_malloc (bytes=3224) at malloc.c:2891
#3 0x77b53e77 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#4 0x77b2b12f in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#5 0x77b86cee in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#6 0x77b87442 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#7 0x77b877b7 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#8 0x77b87a66 in sqlite3_prepare_v2 () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#9 0x77b87b21 in sqlite3_exec () from
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#10 0x004079a1 in list_event (v=0x622d20, account_id=41,
nbr_of_results=10) at event.c:223
#11 0x0040b5a8 in load_account (account_id=41, v=0x622d20) at
account.c:603
#12 0x00401baa in tload_account () at t/test.c:201
#13 0x00402017 in taccount () at t/test.c:271
#14 0x0040369e in all_tests () at t/test.c:668
#15 0x0040374d in main (argc=1, argv=0x7fffe4a8) at
t/test.c:683
The SQL in question is: SELECT id, date, text FROM events WHERE account_id=41
ORDER BY date DESC LIMIT 10
and it works fine running in the sqlite3 program (the query program that
comes with sqlite3).
Now the code above in list_event() has been working before but broke
after a minor change that shouldn't effect sqlite3. I might have done
that, however I don't expect this behaviour from sqlite3.
The code that gives that error could be seen here:
221 if ( v == NULL)
222 flog("view is NULL\n\n");
223 rc = sqlite3_exec(db, "SELECT id, date, text FROM events WHERE
account_id=1 ORDER BY date DESC LIMIT 10" , NULL, NULL, );
224 flog("query done\n");
225
226 if (rc != SQLITE_OK) {
227 flog("ERROR: Could not list events, SQL error:
%s\n\n%s", zErrMsg, q);
228 sqlite3_free(zErrMsg);
229 toret = -1;
230 }
The callback function is never called.
Despite any errors in my code (which I'm sure there's), why does
sqlite3 crash this way?
--
Fredrik Gustafsson
phone: +46 733-608274
e-mail: iveqy at iveqy.com
website: http://www.iveqy.com
[sqlite] Table entries disappearing for unknown reason.
I think I have discovered the problem. SQLiteManager::init( const string&
dbFileName, const bool deleteDbFileFlag = true ) was deleting and
recreating the database file for each new connection. That was probably
corrupting SQLite state and a SQLITE_IOERR_DELETE_NOENT was correctly being
returned at transaction ending, since the original file to write was
replaced by another one. Some multithreaded tests are passing already. I
will finish the tests to put the final verdict here.
2016-02-03 12:56 GMT-02:00 Vin?cius da Silva :
> With a single thread and two interleaved transactions, the tests hangs in
> what seems a deadlock.
>
> 2016-02-03 12:21 GMT-02:00 Clemens Ladisch :
>
>> Vin?cius da Silva wrote:
>> > Using BEGIN EXCLUSIVE TRANSACTION in place of BEGIN TRANSACTION does not
>> > change the result
>>
>> I meant, try executing them so that they are guaranteed to conflict, like
>> this:
>>
>> db1.init("same_file");
>> db2.init("same_file");
>> db1.beginTransactionExclusive();
>> db2.beginTransactionExclusive();
>>
>>
>> Regards,
>> Clemens
>> ___
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
>
> --
> Best Regards,
>
> Vin?cius da Silva ,
> Ph. D. Student.
> PESC - UFRJ
>
--
Best Regards,
Vin?cius da Silva ,
Ph. D. Student.
PESC - UFRJ
[sqlite] Table entries disappearing for unknown reason.
With a single thread and two interleaved transactions, the tests hangs in
what seems a deadlock.
2016-02-03 12:21 GMT-02:00 Clemens Ladisch :
> Vin?cius da Silva wrote:
> > Using BEGIN EXCLUSIVE TRANSACTION in place of BEGIN TRANSACTION does not
> > change the result
>
> I meant, try executing them so that they are guaranteed to conflict, like
> this:
>
> db1.init("same_file");
> db2.init("same_file");
> db1.beginTransactionExclusive();
> db2.beginTransactionExclusive();
>
>
> Regards,
> Clemens
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
--
Best Regards,
Vin?cius da Silva ,
Ph. D. Student.
PESC - UFRJ
[sqlite] Customizing the location of the .sqlite_history
> Jes Slow wrote: > > > Many applications do this by allowing the user to set an environment > > variable to customize the location, altho personally I would prefer > > another way since environment variables are also global. > > Global? Environment variables are per-process, and changeable by the > process with putenv(3). Each process when it starts gets a "copy" of its parent process environment, which it may modify and will be "copied" to its children. The "first process" creates the "first environment" by copying from its parent (NUL) and passing its modifications along to its children.
[sqlite] Bug: Successfully committed transaction rolled back after power failure
Is this on windows? Any errors in the Eventlogs to the tune "Oooopsie -- accidentally threw away your data instead of writing it to disk"? Windows does this quite commonly under some circumstances. MicroSoft created the bug in NT 4 and has been unable to locate or fix it since -- though there is no problem producing an error message about 50% of the time it happens. > -Original Message- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of Yannick Duch?ne > Sent: Tuesday, 2 February, 2016 14:58 > To: sqlite-users at mailinglists.sqlite.org > Subject: Re: [sqlite] Bug: Successfully committed transaction rolled back > after power failure > > On Thu, 28 Jan 2016 14:55:28 + > Simon Slavin wrote: > > > > > On 28 Jan 2016, at 1:38pm, Bernard McNeill wrote: > > > > > === > > > Like the user reading ?saving OK? and throwing away the > > > Post-It with the original information > > > === > > > > > > This is exactly my concern. > > > The user throwing away the Post-It is entirely reasonable if he sees a > > > message like that. > > > > > > Do you happen to know if Linux/Debian (which I think uses a > journalling > > > filesystem) carries this risk? > > > > The problem is not at the software level. Various operating systems and > file systems are correctly programmed with regard to waiting for write > commands to complete. I don't know specifically about Debian but Linux > has a good reputation for such things, and anyone who bothers to write a > journalling file system would understand how to do things properly. > > > > The problem is at the hardware level. Standard disk drives (including > their motherboard if they have one, and their firmware) are designed for > speed, not integrity. The assumption is that you will be using them to > play games or write your CV in Word, not to keep vital data. So they are > set up, using their default jumper positions, to lie. In order to keep > their computer running as fast as possible, instead of > > > > 1) receive write command > > 2) perform write command > > 3) read that bit of disk to confirm the change > > 4) if not, bring SMART system into play and try writing it somewhere > else > > 5) if succeed, tell the computer "I wrote that and it worked." > > 6) otherwise tell the computer "I wrote that and it failed." > > > > they do this > > > > 1) receive write command > > 2) tell the computer "I wrote that and it worked." > > 3) perform write command > > 4) read that bit of disk to confirm the change > > 5) if not, bring SMART system into play and try writing it somewhere > else > > Coincidence. I just had a funny incident; may be it's related. > > I just modified a program so that it create fours triggers in a database. > I ran the program, then got an error from APSW (the program uses Python) > complaining about an I/O or disk error. This frightened me a bit, but I > though this may be due to SQLiteBrowser opened on the same DB, which I > forget to close and I closed just after I started the program, which was > subject to the I/O issue. I open the DB and can see only two of the four > triggers, two missing. So I delete the DB and regenerate it three times, > without error messages, but still two triggers missing. That's only at the > fourth repetition the four triggers was all there. > > The SMART data indicates zero reallocated sectors. > > In the SMART utility, I noticed there is an hardware cache, which I > disabled, in case of and thinking about ?lying devices? I remembered from > this message. > > This is frightening to me, as I got an error message the first time only, > but not the other times while something wrong seems to have happened too. > Also, I could notice something was missing in the DB (even when generated > without an error notification), because it was about something I was > precisely looking at, at that moment; if it had been about some rows > missing in any table, I would have not noticed it. > > Hardware failure? OS failure? Software failure? Can't tell for sure?? > > > > -- > Yannick Duch?ne > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
