Documentation Source Text

Check-in [2eb277d7fc]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Add the isolation.in document. Other changes for 3.8.0.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 2eb277d7fc22de12d5664e78b00ff22f07315257
User & Date: drh 2013-07-12 20:03:31
Context
2013-07-12
20:39
Fix typos in the isolation document. check-in: f64ef462b2 user: drh tags: trunk
20:03
Add the isolation.in document. Other changes for 3.8.0. check-in: 2eb277d7fc user: drh tags: trunk
2013-07-09
21:49
Fix typo in version number for sqlite_stat3. check-in: a583de40a1 user: mistachkin tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/changes.in.

    40     40       hd_close_aux
    41     41       hd_enable_main 1
    42     42     }
    43     43   }
    44     44   
    45     45   chng {2013-08-15 (3.8.0)} {
    46     46   <li>Cut-over to the [next generation query planner] for faster and better query plans.
           47  +<li>The [EXPLAIN QUERY PLAN] output no longer shows an estimate of the number of 
           48  +    rows generated by each loop in a join.
    47     49   <li>Added the [FTS4 notindexed option], allowing non-indexed columns in an FTS4 table.
    48     50   <li>Added the [SQLITE_STMTSTATUS_VM_STEP] option to [sqlite3_stmt_status()].
    49         -<li>Added the "percentile()" function as a loadable extension in the ext/misc
           51  +<li>Added the "percentile()" function as a [loadable extension] in the ext/misc
    50     52       subdirectory of the source tree.
    51     53   <li>A running SELECT statement that lacks a FROM clause (or any other statement that
    52     54       never reads or writes from any database file) will not prevent a read
    53     55       transaction from closing.
    54         -<li>Add the [SQLITE_DEFAULT_AUTOMATIC_INDEX] compile-time option that, if set to 0,
    55         -    disables automatic indices by default.
           56  +<li>Add the [SQLITE_DEFAULT_AUTOMATIC_INDEX] compile-time option.  Setting this option
           57  +    to 0 disables automatic indices by default.
    56     58   <li>Issue an [SQLITE_WARNING_AUTOINDEX] warning on the [SQLITE_CONFIG_LOG] whenever
    57     59       the query planner uses an automatic index.
           60  +<li>Added the [SQLITE_FTS3_MAX_EXPR_DEPTH] compile-time option.
           61  +<li>Added an optional 5th parameter defining the collating sequence to the 
           62  +    next_char() extension SQL function.
           63  +<li>The [SQLITE_BUSY_SNAPSHOT] extended error code is returned in WAL mode when
           64  +    a read transaction cannot be upgraded to a write transaction because the read is
           65  +    on an older snapshot.
           66  +<li>Allow read transactions to be freely opened and closed by SQL statements run 
           67  +    from within the implementation of [application-defined SQL functions] if the
           68  +    function is called by a SELECT statement that does not access any database table.
           69  +<li>Disable the use of posix_fallocate() on all (unix) systems unless the
           70  +    HAVE_POSIX_FALLOCATE compile-time option is used.
           71  +<li>Update the ".import" command in the [command-line shell] to support multi-line
           72  +    fields and correct RFC-4180 quoting and to issue warning and/or error messages
           73  +    if the input text is not strictly RFC-4180 compliant.
           74  +<li>Bug fix: In the [unicode61] tokenizer of [FTS4], treat all private code points
           75  +    as identifier symbols.
           76  +<li>Bug fixes: Multiple problems in the legacy query optimizer were fixed by the 
           77  +    move to [NGQP].
    58     78   }
    59     79   
    60     80   chng {2013-05-20 (3.7.17)} {
    61     81   <li>Add support for [memory-mapped I/O].
    62     82   <li>Add the [sqlite3_strglob()] convenience interface.
    63     83   <li>Assigned the integer at offset 68 in the [database header] as the
    64     84       [Application ID] for when SQLite is used as an [application file-format].

Changes to pages/compile.in.

   148    148   }
   149    149   
   150    150   COMPILE_OPTION {SQLITE_DEFAULT_WAL_AUTOCHECKPOINT=<i>&lt;pages&gt;</i>} {
   151    151     This macro sets the default page count for the [WAL]
   152    152     [checkpointing | automatic checkpointing] feature.  If unspecified,
   153    153     the default page count is 1000.
   154    154   }
          155  +
          156  +COMPILE_OPTION {SQLITE_FTS3_MAX_EXPR_DEPTH=<i>N</i>} {
          157  +  This macro sets the maximum depth of the search tree that corresponds to
          158  +  the right-hand side of the MATCH operator in an [FTS3] or [FTS4] full-text
          159  +  index.  The full-text search uses a recursive algorithm, so the depth of
          160  +  the tree is limited to prevent using too much stack space.  The default
          161  +  limit is 12.  This limit is sufficient for up to 4095 search terms on the
          162  +  right-hand side of the MATCH operator and it holds stack space usage to 
          163  +  less than 2000 bytes.
          164  +  <p>
          165  +  For ordinary FTS3/FTS4 queries, the search tree depth is approximately
          166  +  the base-2 logarithm of the number of terms in the right-hand side of the
          167  +  MATCH operator.  However, for [phrase queries] and [NEAR queries] the
          168  +  search tree depth is linear in the number of right-hand side terms.
          169  +  So the default depth limit of 12 is sufficient for up to 4095 ordinary
          170  +  terms on a MATCH, it is only sufficient for 11 or 12 phrase or NEAR
          171  +  terms.  Even so, the default is more than enough for most application.
          172  +}
   155    173   
   156    174   COMPILE_OPTION {SQLITE_MAX_MMAP_SIZE=<i>N</i>} {
   157    175     This macro sets a hard upper bound on the amount of address space that
   158    176     can be used by any single database for memory-mapped I/O.
   159    177     Setting this value to 0 completely disables memory-mapped I/O and
   160    178     causes logic associated with memory-mapped I/O to be omitted from the
   161    179     build.  This option does change the default memory-mapped I/O address

Changes to pages/fts3.in.

   554    554     <i>-- Query the database for documents for which the term "linux" appears in</i>
   555    555     <i>-- the document title, and the term "driver" appears in the body of the document</i>
   556    556     <i>-- ("driver" may also appear in the title, but this alone will not satisfy the</i>.
   557    557     <i>-- query criteria).</i>
   558    558     SELECT * FROM docs WHERE body MATCH 'title:linux driver';
   559    559   </codeblock>
   560    560   
          561  +<tcl>hd_fragment phrase {phrase queries}</tcl>
   561    562   <ul>
   562    563     <li><p><b>Phrase queries</b>.
   563    564       A phrase query is a query that retrieves all documents that contain a
   564    565       nominated set of terms or term prefixes in a specified order with no
   565    566       intervening tokens. Phrase queries are specified by enclosing a space
   566    567       separated sequence of terms or term prefixes in double quotes (").
   567    568       For example:
................................................................................
   573    574   
   574    575     <i>-- Query for all documents that contain a phrase that matches "lin* app*". As well as</i>
   575    576     <i>-- "linux applications", this will match common phrases such as "linoleum appliances"</i>
   576    577     <i>-- or "link apprentice".</i>
   577    578     SELECT * FROM docs WHERE docs MATCH '"lin* app*"';
   578    579   </codeblock>
   579    580   
          581  +<tcl>hd_fragment near {NEAR queries}</tcl>
   580    582   <ul>
   581    583     <li><p><b>NEAR queries</b>. 
   582    584       A NEAR query is a query that returns documents that contain a two or
   583    585       more nominated terms or phrases within a specified proximity of each 
   584    586       other (by default with 10 or less intervening terms). A NEAR query is 
   585    587       specified by putting the keyword "NEAR" between two phrase, term or 
   586    588       [prefix queries]. To specify a proximity other than the default,

Added pages/isolation.in.

            1  +<title>Isolation In SQLite</title>
            2  +<tcl>hd_keywords isolation</tcl>
            3  +
            4  +<h1 align="center">
            5  +Isolation In SQLite
            6  +</h1>
            7  +
            8  +<p>
            9  +The "isolation" property of a database determines when changes made to 
           10  +the database by one operation become visible to other concurrent operations.
           11  +</p>
           12  +
           13  +<h2>Isolation Between Database Connections</h2>
           14  +
           15  +<p>
           16  +If the same database is being read and written using two different
           17  +[database connections] (two different [sqlite3] objects returned by
           18  +separate calls to [sqlite3_open()]) and the two database connections
           19  +do not have a [shared cache], then the reader is only able to
           20  +see complete committed transactions from the writer.  Partial changes
           21  +by the writer that have not been committed are invisible to the reader.
           22  +This is true regardless of whether the two database connections are in
           23  +the same thread, the different threads of the same process, or in
           24  +different processes.  This
           25  +is the usual and expected behavior for SQL database systems.
           26  +</p>
           27  +
           28  +<p>
           29  +The previous paragraph is also true (separate database connections are
           30  +isolated from one another) in [shared cache mode] as long as the
           31  +[read_uncommitted pragma] remains turned off.  The [read_uncommitted pragma]
           32  +is off by default and so if the application does nothing to turn it on, 
           33  +it will remain off.  Hence, unless the [read_uncommitted pragma] is used
           34  +to change the default behavior, changes made by one database connection
           35  +are invisible to readers on a different database connection sharing the
           36  +same cache until the writer commits its transaction.
           37  +</p>
           38  +
           39  +<p>
           40  +If two database connections shared the same cache and the reader has 
           41  +enabled the [read_uncommitted pragma], then the reader will be able to
           42  +see changes made by the writer before the writer transaction commits.
           43  +The combined use of [shared cache mode] and the [read_uncommitted pragma] 
           44  +is the only way that one database connection can see uncommitted changes
           45  +on a different database connection.  In all other circumstances, separate
           46  +database connections are completely isolated from one another.
           47  +</p>
           48  +
           49  +<p>Except in the case of [shared cache] database connections with
           50  +[PRAGMA read_uncommitted] turned on, all transactions in SQLite show
           51  +"serializable" isolation.  SQLite implements serializable tranactions
           52  +by actually serializing the writes.  There can only be a single writer
           53  +at a time to an SQLite database.  There can be multiple database connections
           54  +open at the same time, and all of those database connections can write
           55  +to the database file, but they have to take turns.  SQLite uses locks
           56  +to serialization of the writes automatically; this is not something that
           57  +the applications using SQLite need to worry with.</p>
           58  +
           59  +
           60  +<h2>Isolation And Concurrency</h2>
           61  +
           62  +<p>
           63  +SQLite implements isolation and concurrency control (and atomicity) using
           64  +transient
           65  +journal files that appear in the same directory in as the database file.
           66  +There are two major "journal modes".
           67  +The older "rollback mode" corresponds to using the "DELETE", "PERSIST",
           68  +or "TRUNCATE" options to the [journal_mode pragma].  In rollback mode,
           69  +changes are written directly into the database file, while simultaneously
           70  +a separate rollback journal file is constructed that is able to restore
           71  +the database to its original state if the transaction rolls back.
           72  +Rollback mode (specifically DELETE mode, meaning that the rollback journal
           73  +is deleted from disk at the conclusion of each transaction) is the current
           74  +default behavior.
           75  +</p>
           76  +
           77  +<p>Since version 3.7.0, SQLite also supports "[WAL mode]".  In WAL mode,
           78  +changes are not written to the original database file.  Instead, changes
           79  +go into a separate "write-ahead log" or "WAL" file.  
           80  +Later, after the transaction
           81  +commits, those changes will be moved from the WAL file back into the
           82  +original database in an operation called "checkpoint".  WAL mode is
           83  +enabled by running "[PRAGMA journal_mode|PRAGMA journal_mode=WAL]".
           84  +</p>
           85  +
           86  +<p>
           87  +In rollback mode, SQLite implements isolation by locking the database
           88  +file and preventing any reads by other database connections
           89  +while each write transaction is underway.
           90  +Readers can be be active at the beginning of a write, before any content
           91  +is flushed to disk and while all changes are still held in the writer's
           92  +private memory space.  But before any changes are made to the database file
           93  +on disk, all readers must be (temporally) expelled in order to give the writer
           94  +exclusive access to the database file.  
           95  +Hence, readers are prohibited from seeing incomplete
           96  +transactions by virtue of being locked out of the database while the
           97  +transaction is being written to disk.  Only after the transaction is
           98  +complete written and synced to disk and commits are the readers allowed
           99  +back into the database.  Hence readers never get a chance to see partially
          100  +written changes.
          101  +</p>
          102  +
          103  +<p>
          104  +WAL mode permits simultenous readers and writers.  It can do this because
          105  +changes do not overwrite the original database file, but rather go
          106  +into the separate write-ahead log file.  That means that readers can continue
          107  +to read the old, original, unaltered content from the original database file
          108  +at the same time that the writer is appending to the write-ahead log.
          109  +In [WAL mode], SQLite exhibits "snapshot isolation".  When a read transaction
          110  +starts, that reader continues to see an unchanging "snapshot" of the database
          111  +file as it existed at the moment in time when the read transaction started.
          112  +Any write transactions that commit while the read transaction is
          113  +active are still invisible to the read transaction, because the reader is
          114  +seeing a snapshot of database file from a prior moment in time.
          115  +</p>
          116  +
          117  +<p>
          118  +An example:  Suppose there are two database connections X and Y.  X starts
          119  +a read transaction using [BEGIN] followed by one or more [SELECT] statements.
          120  +Then Y comes along and runs an [UPDATE] statement to modify the database.
          121  +X can subsequently do a [SELECT] against the records that Y modified but
          122  +X will see the older unmodified entries because Y's changes are all
          123  +invisible to X while X is holding a read transaction.  If X wants to see
          124  +the changes that Y made, then X must ends its read transaction and
          125  +start a new one (by running [COMMIT] followed by another [BEGIN].)
          126  +</p>
          127  +
          128  +<p>
          129  +Another example: X starts a read tranaction using [BEGIN] and [SELECT], then
          130  +Y makes a changes to the database using [UPDATE].  Then X tries to make a
          131  +change to the database using [UPDATE].  The attempt by X to escalate its
          132  +transaction from a read transaction to a write transation fails with an
          133  +[SQLITE_BUSY_SNAPSHOT] error because the snapshot of the database being
          134  +viewed by X is no longer the latest version of the database.  If X were
          135  +allowed to write, it would fork the history of the database file, which is
          136  +something SQLite does not support.  In order for X to write to the database,
          137  +it must first release its snapshot (using [ROLLBACK] for example) then
          138  +start a new transaction with a subsequent [BEGIN].
          139  +</p>
          140  +
          141  +<p>
          142  +If X starts a transaction that will initially only read but X knows it
          143  +will eventually want to write and does not want to be troubled with
          144  +possible SQLITE_BUSY_SNAPSHOT errors that arise because another connection
          145  +jumped ahead of it in line, then X can issue [BEGIN IMMEDIATE] to start
          146  +its transaction instead of just an ordinary BEGIN.  The [BEGIN IMMEDIATE]
          147  +command goes ahead and starts a write transaction, and thus blocks all
          148  +other writers.  If the [BEGIN IMMEDIATE] operation succeeds, then no
          149  +subsequent operations in that transaction will ever fail with an
          150  +[SQLITE_BUSY] error.
          151  +</p>
          152  +
          153  +<h2>No Isolation Between Operations On The Same Database Connection</h2>
          154  +
          155  +<p>SQLite provides isolation between operations in separate database
          156  +connections.  However, there is no isolation between operations that
          157  +occur within the same database connection.</p>
          158  +
          159  +<p>In other words, if X begins a write transaction using [BEGIN IMMEDIATE]
          160  +then issues one or more [UPDATE], [DELETE], and/or [INSERT]
          161  +statements, then those changes are visible to subsequent [SELECT] statements
          162  +that are evaluated in database connection X.  [SELECT] statements on
          163  +a different  database connection Y will show no changes until the X
          164  +transaction commits.  But [SELECT] statements in X will show the changes
          165  +prior to the commit.</p>
          166  +
          167  +<p>^Within a single database connection X, a SELECT statement always sees all
          168  +changes to the database that are completed prior to the start of the SELECT
          169  +statement, whether committed or uncommitted.  And the SELECT statement
          170  +obviously does not see any changes that occur after the SELECT statement
          171  +completes.  But what about changes that occur while the SELECT statement
          172  +is running?  What if a SELECT statement is started and the [sqlite3_step()]
          173  +interface steps through roughly half of its output, then some [UPDATE]
          174  +statements are run by the application that modify the table that the
          175  +SELECT statement is reading, then more calls to [sqlite3_step()] are made
          176  +to finish out the SELECT statement?  Will the later steps of the SELECT
          177  +statement see the changes made by the UPDATE or not?  The answer is that
          178  +this behavior is undefined.  In particular, whether or not the SELECT statement
          179  +sees the concurrent changes depends on which release of SQLite is
          180  +running, the schema of the database file, whether or not [ANALYZE] has
          181  +been run, and the details of the query.  In some cases, it might depend
          182  +on the content of the database file, too.  There is no good way to know whether
          183  +or not a SELECT statement will see changes that were made to the database
          184  +by the same database connection after the SELECT statement was started.
          185  +And hence, developers should diligently avoid writing applications
          186  +that make assumptions about what will occur in that circumstance.</p>
          187  +
          188  +<p>
          189  +If an application issues a SELECT statement on a single table like
          190  +"<i>SELECT rowid, * FROM table WHERE ...</i>" and starts stepping through 
          191  +the output of that statement using [sqlite3_step()] and examining each
          192  +row, then it is safe for the application to delete the current row or
          193  +any prior row using "DELETE FROM table WHERE rowid=?".  It is also safe
          194  +(in the sense that it will not harm the database) for the application to
          195  +delete a row that expected to appear later in the query but has not
          196  +appeared yet.  If a future row is deleted, however, it might happen that
          197  +the row turns up after a subsequent sqlite3_step(), even after it has
          198  +allegedly been deleted.  Or it might not.  That behavior is undefined.
          199  +The application can 
          200  +also INSERT new rows into the table while the SELECT statement is 
          201  +running, but whether or not the new rows appear
          202  +in subsequent sqlite3_step()s of the query is undefined.  And the application
          203  +can UPDATE the current row or any prior row, though doing so might cause 
          204  +that row to reappear in a subsequent sqlite3_step().  As long as the 
          205  +application is prepared to deal with these ambiguities, the operations 
          206  +themselves are safe and will not harm the database file.</p>
          207  +
          208  +<p>
          209  +For the purposes of the previous two paragraphs, two database connections
          210  +that have the same [shared cache] and which have enabled
          211  +[PRAGMA read_uncommitted] are considered to be the same database connection.
          212  +</p>
          213  +
          214  +<h2>Summary</h2>
          215  +
          216  +<ol>
          217  +<li><p>
          218  +Transactions in SQLite are SERIALIZABLE.
          219  +</p>
          220  +
          221  +<li><p>
          222  +Changes made in one database connection are invisible to all other database
          223  +connections prior to commit.
          224  +</p>
          225  +
          226  +<li><p>
          227  +A query sees all changes that are completed on the same database connection
          228  +prior to the start of the query, regardless of whether or not those changes
          229  +have been committed.
          230  +</p>
          231  +
          232  +<li><p>
          233  +If changes occur on the same database connection after a query 
          234  +starts running but before the query completes, then it is undefined whether 
          235  +or not the query will see those changes.
          236  +</p>
          237  +
          238  +<li><p>
          239  +If changes occur on the same database connection after a query 
          240  +starts running but before the query completes, then the query might return
          241  +a changed row more than once, or it might return a row that was previously
          242  +deleted, or not; the behavior is undefined.
          243  +</p>
          244  +
          245  +<li><p>
          246  +For the purposes of the previous four items, two database connections that 
          247  +use the same [shared cache] and which enable [PRAGMA read_uncommitted] are
          248  +considered to be the same database connection, not separate database
          249  +connections.
          250  +</p>
          251  +</ol>

Changes to pages/lang.in.

   327    327   transactions.  ^An attempt to invoke the BEGIN command within
   328    328   a transaction will fail with an error, regardless of whether
   329    329   the transaction was started by [SAVEPOINT] or a prior BEGIN.
   330    330   ^The COMMIT command and the ROLLBACK command without the TO clause
   331    331   work the same on [SAVEPOINT] transactions as they do with transactions
   332    332   started by BEGIN.</p>
   333    333   
          334  +<tcl>hd_fragment immmediate {BEGIN IMMEDIATE} {BEGIN EXCLUSIVE}</tcl>
   334    335   <p>
   335    336   ^Transactions can be deferred, immediate, or exclusive.  
   336    337   ^The default transaction behavior is deferred.
   337    338   ^Deferred means that no locks are acquired
   338    339   on the database until the database is first accessed.  ^Thus with a
   339    340   deferred transaction, the BEGIN statement itself does nothing to the
   340    341   filesystem.  ^Locks

Changes to pages/loadext.in.

     1      1   <title>Run-Time Loadable Extensions</title>
     2      2   <tcl>hd_keywords {loadext} {loadable extensions} {extension loading} \
     3         -                 {SQLite extension} {SQLite extensions}</tcl>
            3  +                 {SQLite extension} {SQLite extensions} \
            4  +                 {loadable extension}</tcl>
     4      5   
     5      6   <h1 align="center">Run-Time Loadable Extensions</h1>
     6      7   
     7      8   <p>SQLite has the ability to load extensions (including new
     8      9   [application-defined SQL functions],
     9     10   [collating sequences], [virtual tables], and [VFSes]) at run-time.
    10     11   This feature allows the code for extensions to be developed and
................................................................................
   201    202     **     sqlite3_create_module_v2(), and/or
   202    203     **     sqlite3_vfs_register()
   203    204     ** to register the new features that your extension adds.
   204    205     */
   205    206     return rc;
   206    207   }
   207    208   </pre></blockquote>
          209  +
          210  +<p>Many examples of complete and working loadable extensions can be seen in the
          211  +SQLite source tree in the
          212  +<a href="http://www.sqlite.org/src/dir?name=ext/misc&ci=trunk">ext/misc</a>
          213  +subdirectory.</p>
   208    214   
   209    215   <h2>Statically Linking A Run-Time Loadable Extension</h2>
   210    216   
   211    217   <p>The exact same source code can be used for both a run-time loadable
   212    218   shared library or DLL and as a module that is statically linked with your
   213    219   application.  This provides flexibility and allows you to reuse the same
   214    220   code in different ways.</p>

Changes to pages/news.in.

    14     14     hd_puts "<h3>$date - $title</h3>"
    15     15     regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
    16     16     regsub -all {[Tt]icket #(\d+)} $txt \
    17     17         {<a href="http://www.sqlite.org/cvstrac/tktview?tn=\1">\0</a>} txt
    18     18     hd_resolve "<blockquote>$txt</blockquote>"
    19     19     hd_puts "<hr width=\"50%\">"
    20     20   }
           21  +
           22  +newsitem {2013-08-15} {Release 3.8.0} {
           23  +  SQLite [version 3.8.0] features the cutover of the
           24  +  [next generation query planner] or [NGQP].
           25  +  The NGQP will normally cause applications to run faster.  However,
           26  +  there are [hazards of upgrading to the NGQP | hazards] associated
           27  +  with this upgrade.  A [query planner checklist] is available to
           28  +  application developers to aid in avoiding problems.
           29  +}
    21     30   
    22     31   newsitem {2013-05-20} {Release 3.7.17} {
    23     32     SQLite [version 3.7.17] is a regularly schedule maintenance release.
    24     33     Visit the [version 3.7.17 | change log] for a full explanation of the
    25     34     changes in this release.
    26     35   
    27     36     There are many bug fixes in version 3.7.17.  But this does not indicate

Changes to pages/support.in.

    57     57   
    58     58   <tcl>hd_fragment mailinglists {mailing lists}</tcl>
    59     59   <h3>Mailing Lists</h3>
    60     60   <p>Three separate mailing lists have been established to help support
    61     61   SQLite:</p>
    62     62   
    63     63   <ul>
           64  +<li><a href="http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users">
           65  +sqlite-users</a> - general discussion for programmers using SQLite in their applications.  
           66  +Most postings belong here.</li>
           67  +<li><a href="http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-dev">
           68  +sqlite-dev</a> - conversations about SQLite internals, for those who work
           69  +directly on enhancing SQLite itself.</li>
    64     70   <li><a href="http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-announce">
    65     71   sqlite-announce</a> - announcements of new
    66         -releases or significant developments.</li>
    67         -<li><a href="http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users">
    68         -sqlite-users</a> - general user discussion; most postings belong here.</li>
    69         -<li><a href="http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-dev">
    70         -sqlite-dev</a> - developer conversations; for people who have or aspire to
    71         -have write permission on the SQLite source code repository.</li>
           72  +releases or significant developments; a very-low traffic list.</li>
    72     73   </ul>
    73     74   
    74     75   <p>
    75     76   Most users of SQLite will want to join the
    76     77   <a href="http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-announce">
    77     78   sqlite-announce</a> list and many will want to join the
    78     79   <a href="http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users">
................................................................................
    87     88   <blockquote>
    88     89   [http://www.mail-archive.com/sqlite-users%40sqlite.org/]<br>
    89     90   <a href="http://marc.info/?l=sqlite-users&r=1&w=2">http://marc.info/?l=sqlite-users&r=1&w=2</a><br>
    90     91   [http://news.gmane.org/gmane.comp.db.sqlite.general]
    91     92   </blockquote>
    92     93   
    93     94   </p>
    94         -
    95         -<a name="directemail"></a>
    96         -<h3>Direct E-Mail To The Author</h3>
    97         -
    98         -<p>
    99         -Use the mailing list.
   100         -Please do <b>not</b> send email directly to the author of SQLite
   101         -unless:
   102         -<ul>
   103         -<li>You have or intend to acquire a professional support contract
   104         -as described above, or</li>
   105         -<li>You are working on an open source project.</li>
   106         -</ul>
   107         -You are welcomed to use SQLite in closed source, proprietary, and/or
   108         -commercial projects and to ask questions about such use on the public
   109         -mailing list.  But please do not ask to receive free direct technical
   110         -support.  The software is free; direct technical support is not.
   111         -</p>