[sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

[Keith Medcalf]

Hrm.  Inconsistent/incorrect results.  Consider:

create table a(id integer primary key, a);
insert into a values (1,1), (2,1), (3,1);
create table b(id integer primary key, b);
insert into b values (1,2), (3,2), (4,2);
create table c(id integer primary key, c);
insert into c values (1,3), (4,3), (5,3);

select * from a, b, c using (id); -- very strange result

id  a   id  b   c
--  --  --  --  --
1   1   1   2   3
1   1   3   2   3
1   1   4   2   3

select * from a, b using (id), c using (id); -- correct result

id  a   b   c
--  --  --  --
1   1   2   3

The first query should be processed as:

select * from a, b, c where b.id == c.id;

id  a   id  b   id  c
--  --  --  --  --  --
1   1   1   2   1   3
2   1   1   2   1   3
3   1   1   2   1   3
1   1   4   2   4   3
2   1   4   2   4   3
3   1   4   2   4   3

but with the c.id (third id column omitted).

Or it should be processed as the second query if the "using (id)" constraint 
applies to everywhere an "id" field is found, not just the LHS and RHS tables 
of the immediately proceeding join.

also 
select * from a natural join b natural join c;
-- returns no rows despite the column "id" existing commonly in all tables

This is with the current development release (and as far as I can tell, all 
prior versions).

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: sqlite-users  On
>Behalf Of Keith Medcalf
>Sent: Saturday, 4 January, 2020 19:32
>To: SQLite mailing list 
>Subject: Re: [sqlite] SQLite command-line result is different from Perl
>DBI::Sqlite result
>
>
>
>
>
>--
>The fact that there's a Highway to Hell but only a Stairway to Heaven
>says a lot about anticipated traffic volume.
>
>On Saturday, 4 January, 2020 18:31, Amer Neely 
>wrote:
>
>>I'm fairly new to SQLite, but have been using MySQL / mariadb in a local
>>and web-based environment for several years. So far I'm happy and
>>impressed with SQLite, but I recently noticed some odd behaviour with
>>one of my queries.
>>Using the command-line in a shell (Mac High Sierra) I get a particular
>>result from a query. The exact same query in a Perl script gives me a
>>different result. To my mind it is a simple query, getting the 5 latest
>>additions to my music library.
>>Command-line:
>>select artists.artist, artists.artistid, cds.title, cds.artistid,
>>cds.cdid, genres.genre, genres.artistid from artists, genres inner join
>>cds using (artistid) group by artists.artistid order by cds.id desc
>>limit 5;
>>gives me the correct result. However, in a Perl script it gives me a
>>different result. How is that possible? Could it be a Perl::DBI issue?
>>Many thanks for anyone able to shed some light on this.
>
>Your select does not constrain artists so the result is non-deterministic
>in that the result will depend on how the query planner decides to
>execute the query.  That is, you have not specified any join constraints
>on artists.
>
>SELECT * FROM A, B JOIN C USING (D);
>
>means
>
>SELECT *
>  FROM A, B, C
> WHERE B.D == C.D;
>
>if you thought it meant
>
>SELECT *
>  FROM A, B, C
> WHERE A.D == B.D
>   AND B.D == C.D;
>
>then that is likely the reason for the discrepancy.
>
>
>
>
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite command-line result is different from Perl DBI::Sqlite result

[Keith Medcalf]

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

On Saturday, 4 January, 2020 18:31, Amer Neely  wrote:

>I'm fairly new to SQLite, but have been using MySQL / mariadb in a local
>and web-based environment for several years. So far I'm happy and
>impressed with SQLite, but I recently noticed some odd behaviour with
>one of my queries.
>Using the command-line in a shell (Mac High Sierra) I get a particular
>result from a query. The exact same query in a Perl script gives me a
>different result. To my mind it is a simple query, getting the 5 latest
>additions to my music library.
>Command-line:
>select artists.artist, artists.artistid, cds.title, cds.artistid,
>cds.cdid, genres.genre, genres.artistid from artists, genres inner join
>cds using (artistid) group by artists.artistid order by cds.id desc
>limit 5;
>gives me the correct result. However, in a Perl script it gives me a
>different result. How is that possible? Could it be a Perl::DBI issue?
>Many thanks for anyone able to shed some light on this.

Your select does not constrain artists so the result is non-deterministic in 
that the result will depend on how the query planner decides to execute the 
query.  That is, you have not specified any join constraints on artists.

SELECT * FROM A, B JOIN C USING (D);

means

SELECT * 
  FROM A, B, C
 WHERE B.D == C.D;

if you thought it meant

SELECT *
  FROM A, B, C
 WHERE A.D == B.D
   AND B.D == C.D;

then that is likely the reason for the discrepancy.




___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite command-line result is different from Perl DBI::Sqlite result

[Igor Korot]

Hi,

On Sat, Jan 4, 2020 at 7:31 PM Amer Neely  wrote:
>
> Hello all,
> I'm fairly new to SQLite, but have been using MySQL / mariadb in a local
> and web-based environment for several years. So far I'm happy and
> impressed with SQLite, but I recently noticed some odd behaviour with
> one of my queries.
> Using the command-line in a shell (Mac High Sierra) I get a particular
> result from a query. The exact same query in a Perl script gives me a
> different result. To my mind it is a simple query, getting the 5 latest
> additions to my music library.
> Command-line:
> select artists.artist, artists.artistid, cds.title, cds.artistid,
> cds.cdid, genres.genre, genres.artistid from artists, genres inner join
> cds using (artistid) group by artists.artistid order by cds.id desc
> limit 5;
> gives me the correct result. However, in a Perl script it gives me a
> different result. How is that possible? Could it be a Perl::DBI issue?
> Many thanks for anyone able to shed some light on this.

What is your version of Perl and the SQLite module?

Thank you.

> --
> Amer Neely
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite command-line result is different from Perl DBI::Sqlite result

[Amer Neely]

Hello all,
I'm fairly new to SQLite, but have been using MySQL / mariadb in a local
and web-based environment for several years. So far I'm happy and
impressed with SQLite, but I recently noticed some odd behaviour with
one of my queries.
Using the command-line in a shell (Mac High Sierra) I get a particular
result from a query. The exact same query in a Perl script gives me a
different result. To my mind it is a simple query, getting the 5 latest
additions to my music library.
Command-line:
select artists.artist, artists.artistid, cds.title, cds.artistid,
cds.cdid, genres.genre, genres.artistid from artists, genres inner join
cds using (artistid) group by artists.artistid order by cds.id desc
limit 5;
gives me the correct result. However, in a Perl script it gives me a
different result. How is that possible? Could it be a Perl::DBI issue?
Many thanks for anyone able to shed some light on this.
-- 
Amer Neely
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Performance

[Keith Medcalf]

So here is another (this time real world) example using program I wrote which 
runs ~11 million initial connection packets against ~1800 firewall rules.  It 
is written in Python and is inherently single-threaded.  The only 
multithreading is SQLite3's internal threaded sorting.

SINGLETHREAD  MEMSTAT ON   Elapsed 04:06.960013  MPR=1.00
SINGLETHREAD  MEMSTAT OFF  Elapsed 04:04.882091  MPR=1.00
SERIALIZEDMEMSTAT ON   Elapsed 02:11.573467  MPR=1.87
SERIALIZEDMEMSTAT OFF  Elapsed 02:11.771519  MPR=1.93
MULTITHREADED MEMSTAT ON   Elapsed 02:11.445074  MPR=1.87
MULTITHREADED MEMSTAT OFF  Elapsed 02:10.753321  MPR=1.94

If you consider milliseconds to be performance significant for something that 
takes two minutes to run, then MULTITHREADED and MEMSTAT 0 wins both for 
elapsed time and MPR.  However, IMHO, the only valid difference is that 
permitting internal multithreading makes a significant difference and I would 
leave the default of SERIALIZED and MEMSTAT ON since there is no significant 
advantage to changing/disabling those features.

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.




___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Upgrading from version 3.6.16 to 3.30.1

[Warren Young]

On Jan 4, 2020, at 12:49 PM, Gerry Snyder  wrote:
> 
> On Fri, Jan 3, 2020 at 10:57 AM Richard Watt  wrote:
> 
>> Does anyone know of any potential issues I might encounter and how to
>> correct them please?
>> 
> Few packages are maintained with more care about backward compatibility
> than SQLite.
> 
> The best estimate for number of issues you will run into is Zero.

My largest application using SQLite has run into a few of them over the years.

I ran into one just a month or so ago when we tried to slurp a legacy static 
SQL file into SQLite and it rejected it because we were relying on the 
double-quoted string misfeature and didn’t catch all of the uses of it when we 
followed the advice accompanying the 3.29.0 release to disable support for it.

(Our main-line app code doesn’t use the misfeature, only this one canned SQL 
file that’s rarely used, thus the lag in discovery.)

My advice is to try a blind upgrade, and if that fails, first try to find out 
why and use the ChangeLog referenced by J. King to find the reason, and if you 
can’t do that, then begin bisecting the change history.  Halfway between 
current and 3.6.16 is the famous “pi” release (3.14), then halfway again is 
3.22, and so on.

There have been 116 releases (!) since 3.6.16, so the maximum number of 
releases you’ll have to try with a binary bisect is 7.  No big.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

[Keith Medcalf]

Well, actually, no.  

It was a single process that spins up 64 threads each of which accesses its own 
per-thread in-memory database using an 
in-that-thread-only-in-thread-database-connection-in-that-thread.

Making some simple modifications (changing the number of threads to 6 and the 
insertions/thread to 1,000,000 -- so as to consume no more resources than are 
available (this is on a 4-core Xeon (2 SMT threads per core) 32 GB RAM Win10 
1909) yields interesting results (CPU usage was about 90% for all of them, 
though of course the linear runs consumed only 1 thread on one core so about 
12.5% CPU):

SERIALIZED   MEMSTATUS ON   Elapsed Time :  00:00:19.944  MPR=0.75
SERIALIZED   MEMSTATUS OFF  Elapsed Time :  00:00:04.408  MPR=3.97
MULTITHREAD  MEMSTATUS ON   Elapsed Time :  00:00:19.815  MPR=0.72
MULTITHREAD  MEMSTATUS OFF  Elapsed Time :  00:00:04.456  MPR=2.88

*MPR is the Multiprogramming Ratio:  (elapsed time running the workload 
linearly)/(elapsed time running the workload in parallel)

In this case the "linear" time is obtained by running the same test with the 
pthread_join immediately following the pthread_create so that only one thread 
of the workload runs at a time, one after each.

So I conclude that SERIALIZED/MULTITHREAD makes very little difference and that 
MEMSTATUS ON/OFF makes a huge difference.  Since the difference between 
MUTITHREAD and SERIALIZED is a thread mutex on the connection, I can conclude 
that with zero contention for that mutex, whether it is being used or not makes 
little difference and that the fact that it is, when used, a double-indexed 
indirect call through a global data area, leads me to believe that the benefit 
derived from replacing that double-indexed indirect call with an immediate call 
cannot possibly have any significant effect if the elimination of that call 
entirely has negligible effect.

From the MPR _for_this_workload_on_this_particular_CPU_ I can conclude that if 
one wishes to have MEMSTATUS enabled, then using multiple threads is 
detrimental to performance and that linear processing is significantly more 
efficient.  However, when MEMSTATUS is turned off, then serialized mode leads 
to significant increased multiprogramming benefit.

GCC 8.1.0 (MinGW-x64)
gcc -m64 -mwin32 -mconsole -mthreads -O3 -s -pipe 
-Wl,-Bstatic,--nxcompat,--dynamicbase test.c -ID:\Source\bld 
-ID:\Source\bld\tsrc -Ld:\source\bld\gcc\64 -lsqlite3.dll -o test.exe 
-static-libgcc -lpthread

sqlite3.dll compiled using:
gcc -s -O3 -pipe -D_HAVE_SQLITE_CONFIG_H -DSQLITE_EXTRA_INIT=core_init 
-DSQLITE_HAVE_ZLIB -Itsrc -march=native -mtune=native -m64 -mdll -mthreads 
-Wl,-Bstatic,--nxcompat,--dynamicbase,--high-entropy-va,--image-base,0x18000,--out-implib,gcc/64/libsqlite3.dll.a,--output-def,gcc/64/sqlite3.def
 sqlite3.c sqlite3.def -ladvapi32 -lrpcrt4 -lwinmm -lz -static-libgcc -o 
gcc/64/sqlite3.dll

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: sqlite-users  On
>Behalf Of Doug
>Sent: Saturday, 4 January, 2020 10:42
>To: 'SQLite mailing list' 
>Subject: Re: [sqlite] FW: Questions about your "Performance Matters" talk
>re SQLite
>
>Thanks, Jens. I got it. The benchmark sounds like it isn't a real
>benchmark, but a made-up scenario to exercise the Coz code. I've let go
>now.
>Doug
>
>> -Original Message-
>> From: sqlite-users 
>> On Behalf Of Jens Alfke
>> Sent: Friday, January 03, 2020 10:58 PM
>> To: SQLite mailing list 
>> Cc: em...@cs.umass.edu; curtsin...@grinnell.edu
>> Subject: Re: [sqlite] FW: Questions about your "Performance
>> Matters" talk re SQLite
>>
>>
>> > On Jan 2, 2020, at 11:54 AM, Doug  wrote:
>> >
>> > I know there has been a lot of talk about what can and cannot be
>> done with the C calling interface because of compatibility issues
>> and the myriad set of wrappers on various forms. I’m having a hard
>> time letting go of a possible 25% performance improvement.
>>
>> This was a heavily multithreaded benchmark (64 threads accessing
>> the same connection) on a very hefty server-class CPU. From Dr
>> Hipp’s results, it sounds like the speed up may be only in similar
>> situations, not to more normal SQLite usage.
>>
>> —Jens
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
>> users
>
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Upgrading from version 3.6.16 to 3.30.1

[J. King]

On January 3, 2020 12:57:14 p.m. EST, Richard Watt  wrote:
>I'm currently updating a C# .NET application that uses SQLite 3.6.16 to
>run under a new Siemens Sinumerik version and I'd also like to update
>it
>to use the latest SQLite, which is 3.30.1.
>
>Does anyone know of any potential issues I might encounter and how to
>correct them please? I've tried a Google search but not really finding
>much that helps.
>
>Best regards,
>
>-- 
>Richard Watt
>
>
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Search  for the words "incompatible" and 
"legacy", for a start, and review the version history in general. 
-- 
J. King
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Upgrading from version 3.6.16 to 3.30.1

[Gerry Snyder]

On Fri, Jan 3, 2020 at 10:57 AM Richard Watt  wrote:

> I'm currently updating a C# .NET application that uses SQLite 3.6.16 to
> run under a new Siemens Sinumerik version and I'd also like to update it
> to use the latest SQLite, which is 3.30.1.
>
> Does anyone know of any potential issues I might encounter and how to
> correct them please? I've tried a Google search but not really finding
> much that helps.
>
> Best regards,
>
> --
> Richard Watt
>
>
 Few packages are maintained with more care about backward compatibility
than SQLite.

The best estimate for number of issues you will run into is Zero.

Gerry Snyder
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Questions about your "Performance Matters" talk re SQLite

[Simon Slavin]

On 4 Jan 2020, at 5:49pm, Doug  wrote:

> for (i=1000; i--; i>0);

If you have optimization turned on, your compiler might turn that into "i = 0". 
 Optimization messes with a lot of benchmarks.  Checking which optimization 
setting was used is one aspect of what Howard Chu was talking about: benchmark 
figures in isolation don't mean much.

I'm not a big fan of general statements about which form is faster, uses less 
memory, whatever, than which other form.  I want to say "try both ways and keep 
the one which is best".
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

[Doug]

> -Original Message-
> From: sqlite-users 
> On Behalf Of J Decker
> Sent: Saturday, January 04, 2020 4:11 AM
> 
> Could wish there was a way to
> pause execution without giving up execution context...

What about?
for (i=1000; i--; i>0);

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

[Doug]

Thanks, Jens. I got it. The benchmark sounds like it isn't a real benchmark, 
but a made-up scenario to exercise the Coz code. I've let go now.
Doug

> -Original Message-
> From: sqlite-users 
> On Behalf Of Jens Alfke
> Sent: Friday, January 03, 2020 10:58 PM
> To: SQLite mailing list 
> Cc: em...@cs.umass.edu; curtsin...@grinnell.edu
> Subject: Re: [sqlite] FW: Questions about your "Performance
> Matters" talk re SQLite
> 
> 
> > On Jan 2, 2020, at 11:54 AM, Doug  wrote:
> >
> > I know there has been a lot of talk about what can and cannot be
> done with the C calling interface because of compatibility issues
> and the myriad set of wrappers on various forms. I’m having a hard
> time letting go of a possible 25% performance improvement.
> 
> This was a heavily multithreaded benchmark (64 threads accessing
> the same connection) on a very hefty server-class CPU. From Dr
> Hipp’s results, it sounds like the speed up may be only in similar
> situations, not to more normal SQLite usage.
> 
> —Jens
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
> users

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

[J Decker]

On Sat, Jan 4, 2020 at 2:59 AM Howard Chu  wrote:

> Keith Medcalf wrote:
> >
> > Indeed turning off memstatus leads to a 500% (from ~3s to ~0.5s)
> performance increase.
> > Changing the threading mode or the indirection level of the mutexes
> calls seems to have no significant effect.
> >
> Goes to show - publishing benchmark results without investigating why they
> are what
> they are is mostly pointless. When you suspect mutex contention is a
> significant
> factor, you should use something like mutrace to confirm your suspicion
> first.
>
> Fundamentally there ought to be no performance difference between running
> a 64-threaded
> server on a 64-threaded CPU vs 64 single-threaded processes. In practice,
> the single
> process with 64 threads ought to be slightly faster, due to less context
> switch overhead
> between threads, but if nothing else in the system is contending for CPU
> then context
> switching shouldn't even be an issue.
>

but, if the mutex lock always does a 'sched_yield' when the locking fails,
then a failure to lock isn't just a stutter in the thread, but can result
in at least 2 more context switches every time.  Probably something simpler
like a simple InterlockedExchange() call in a loop could maintain locking,
and affect performance much less; since it sounds like the actual lock
duration is really only a few clocks anyway.  Could wish there was a way to
pause execution without giving up execution context...


>
> --
>   -- 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-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

[Howard Chu]

Keith Medcalf wrote:
> 
> Indeed turning off memstatus leads to a 500% (from ~3s to ~0.5s) performance 
> increase.  
> Changing the threading mode or the indirection level of the mutexes calls 
> seems to have no significant effect.
> 
Goes to show - publishing benchmark results without investigating why they are 
what
they are is mostly pointless. When you suspect mutex contention is a significant
factor, you should use something like mutrace to confirm your suspicion first.

Fundamentally there ought to be no performance difference between running a 
64-threaded
server on a 64-threaded CPU vs 64 single-threaded processes. In practice, the 
single
process with 64 threads ought to be slightly faster, due to less context switch 
overhead
between threads, but if nothing else in the system is contending for CPU then 
context
switching shouldn't even be an issue.

-- 
  -- 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-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about passwords in System.Data.Sqlite

[Warren Young]

On Jan 4, 2020, at 12:23 AM, Mike King  wrote:
> 
> This is the subject:
> 
> Hex Password with System.Data.Sqlite (.Net Core)

My Python-fu sucks, but I don’t think that can match the administrivia rule:


https://gitlab.com/mailman/mailman/blob/master/src/mailman/rules/administrivia.py

It looks like what actually happened is that “password” happened to be the 
first word on a line followed by two other words.  (Thus “(2, 2)” at the top of 
that file.)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users