Re: [sqlite] Massively multithreaded SQLite queries

[Andrew Brown]

Although I had experimented with this at great length while I was still running 
a multithreaded model, after switching to the multi process model, I did some 
minor experimentation but it was already extremely fast and it didn't show 
significant gains. Going forward I do intend to experiment with it further now 
that my service is live in production.

Thanks,
Andrew

-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Vikas Aditya
Sent: Wednesday, June 7, 2017 10:56 AM
To: SQLite mailing list 
Subject: Re: [sqlite] Massively multithreaded SQLite queries

Hi Andrew,

This is a great use case for SQLite. Did you have to use any special flags or 
settings for SQLite to achieve this e.g. cache size, page size Read only etc?

Thanks,
Vikas


> On Jun 7, 2017, at 10:07 AM, Andrew Brown  
> wrote:
> 
> Wanted to just let you all know that I really appreciated the help you 
> offered when I asked this a few months ago.
> 
> Since then, I've jettisoned the idea of using multiple threads and moved to 
> using multiple processes instead. I have built out an API that accepts http 
> requests for queries, chunks them into deterministic jobs (which improves the 
> probability of a cache hit), which are combined with the operation that needs 
> to be run on the job and hashed, sent via 0mq to the many dbnode processes 
> that are running, where the dbnode checks the cache for the hash in question, 
> and if it does not exist, then queries the Sqlite databases for the result. 
> From there the subqueries are sent back to the coordinator in the API node 
> and combined into the result set for the client.
> 
> It's really fast. It wouldn't be great if I had to write data, but as a data 
> slicer against fixed data, it's pretty slick.
> 
> Just want to thank those who responded and also those who have created and 
> contributed to SQLite as it's a pretty fantastic way to filter through a few 
> terabytes of information - many billions of rows, in mere milliseconds - even 
> more so when parallelized like this.
> 
> 
> 
> 
> 
> From: Andrew Brown
> Sent: Friday, March 3, 2017 12:14 PM
> To: 'sqlite-users@mailinglists.sqlite.org' 
> 
> Subject: Massively multithreaded SQLite queries
> 
> Hello,
> 
> Based on my reading of the documentation it seems like SQLite is a great 
> candidate for cases where you have a large number of threads that only need 
> to read a database simultaneously, in our case for fast data lookup, 
> aggregation, etc. I've been able to generate SQL queries that do this, but 
> once we start running them on a large server with a lot of multithreading 
> going on, I find that we spend a lot of time in __raw_spin_lock - perhaps 
> 75%+ of the time (In one case, 87% of 350 seconds x 72 cores was spent in 
> __raw_spin_lock). This is being run on 64 and 72 core machines, and the more 
> cores I run it on, the slower it ends up going.
> 
> To give a bit more detail, I'm working with dotnet core, have written a 
> custom sqlite wrapper (since the dotnet core one lacks the ability to set 
> connection flags beyond readonly, and doesn't have sqlite_prepare_v2() 
> implemented), and I'm running on linux against a bunch of SQLite files in the 
> 2gb-400gb size range. Individual queries are wicked fast, but once I start 
> spreading the load over all the cores by running simultaneous queries I lose 
> the performance advantage and it actually becomes significantly slower.
> 
> Have tried setting SQLITE_OPEN_NOMUTEX, SQLITE_OPEN_FULLMUTEX. Tried shared 
> cache, read uncommitted. Tried without shared cache, read uncommitted. Tried 
> WAL. If I write a less efficient query, I spend less time in __raw_spin_lock, 
> but of course then it takes longer for the queries themselves to return.
> 
> Any tips to handle massively multithreaded side by side chunked queries on 
> the same database?
> 
> Thank you in advance,
> Andrew Brown
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailinglists.sqlite.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsqlite-users&data=01%7C01%7Candrew.brown%40economicmodeling.com%7C4ca732c6b31d453093b408d4adce8ae4%7C7cc1677566a34e8b80fd5b1f1db15061%7C0&sdata=M6UfvrnKuMTk3CiL8%2BBfRwgXj9J1aPK1%2By0H9Om8Fmw%3D&reserved=0

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailinglists.sqlite.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsqlite-users&data=01%7C01%7Candrew.brown%40economicmodeling.com%7C4ca732c6b31d453093b408d4adce8ae4%7C7cc1677566a34e8b80fd5b1f1db15061%7C0&sdata=M6UfvrnKuMTk3CiL8%2BBfRwgXj9J1aPK1%2By0H9Om8Fmw%3D&reserved=0
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listin

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

2017-06-07 13:57 GMT-04:00 Simon Slavin :

> The work of parsing comments in the CREATE TABLE command ?  I don’t think
> anyone else thinks this is worth working on.  Discussion in this list has
> come up with many reasons why it’s a poor way to store comments, including
>
i'm aware of them.. but its a limited support:


> * Difficulty of parsing text which may have CR, LT, tab, comma, etc..
>
use standard way, only LF no comma and TAB allowed.. POSIX always


> * Impossible to update the comments without DROPping and reCREATEing the
> table because SQLite implements only a few ALTER TABLE commands.
>
umm that's enough for limited support!


> * Documentation restricted to one language.
>
i dont understant the meaning of, why multilang comments...?


>
> Here’s a simple version of the best system I ever came up with from
> working in multi-programmer projects, where clear comments were important
> to letting one developer know what another intended.  Comments for a
> database can be stored in the following table in that database:
>
> CREATE TABLE meta_comments (
> entityType TEXT COLLATE NOCASE NOT NULL,
> theTable TEXT COLLATE NOCASE NOT NULL,
> theName TEXT COLLATE NOCASE NOT NULL,
> theComment TEXT COLLATE NOCASE NOT NULL,
> PRIMARY KEY (entityType, theTable, theName));
>
> Values for "entityType" can be ’schema’,'table','index','trigger','view',
> and anything else you want to document.
>
that its a good limited aproach! limit the comments to only 12 chars to not
overhead the db size


>
> If you need multilanguage documentation (required for some countries which
> work to protect a language) add a "language TEXT COLLATE NOCASE NOT NULL"
> field and include it in the primary key.  Ih one use of an early version of
> this we also used a field called "theVersion" to document changes in each
> entity, though I don’t know how sensible that is for most uses.  We also
> used to use a table like this to store commands, though if I was designing
> that system from scratch now I’d use a different table.
>

the mayor problem its when sqlite join two files/databases to share the
comments with the other

>
> I came up with the above structure myself, warrant that it is not
> encumbered by any intellectual property, and dedicate it to the public
> domain.  Anyone can use it for anything they want.
>
that its good...enought


>
> Simon.
> ___
> 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] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

ipost github as example.. there a sourceforge git capabilities over large
years.. also  You can't be 100% certain that Ricahd resources is going to
be online tomorrow.. sf.net, github, gitlab and googlecode are still only
voer many years... and all of them works with openid...

for Stephen Chrzanowski  and Simon Slavin thans for their responses,
i-ll (due the stric wrokflow of old-behaviour of maillist software) will
answer in another mail to conserver the threath workflow (that its not
happened in a real issue tracker)

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-06-07 12:37 GMT-04:00 Stephen Chrzanowski :

> Why should Richard and other devs rely on something other than their own
> work and source control?  You can't be 100% certain that GitHub is going to
> be online tomorrow, which means that a scramble to push code to another
> site is going to happen.  You can't be certain that whatever comes after
> GitHub and becomes the default place to go for public code repository.
>
> What Richard has put in place is entirely under his control, his management
> style, his methodologies, and his implementation.  21st century or not,
> he's not a lemming and doesn't have to jump on the next bandwagon.
>
> As for the comment about registration, you need to register to get onto
> GitHub as well.  So outside a mail client of my choice, I now have to worry
> about a web browser and trust that the remote site is going to be
> available, what the provider is going to do with my information.
>
>
>
> On Wed, Jun 7, 2017 at 12:17 PM, PICCORO McKAY Lenz <
> mckaygerh...@gmail.com>
> wrote:
>
> > hello brian, what standars? reading deeply the sqlite site i not see the
> > @issue buton@
> >
> > only see that all contact way must be in the mail list... its a 21
> century
> > and ID urls its the standar way of integration...
> >
> > Lenz McKAY Gerardo (PICCORO)
> > http://qgqlochekone.blogspot.com
> >
> > 2017-06-07 12:12 GMT-04:00 Brian Curley :
> >
> > > Not exactly.
> > >
> > > You're free to extend it yourself and submit it for consideration
> > though. I
> > > think that you'll just need to adopt the same standards as are in use
> > > within the usual enhancements channels.
> > >
> > > Regards.
> > >
> > > Brian P Curley
> > >
> > >
> >
> ___
> 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] WAL checkpoint starved?

[Daniel Polski]

Den 2017-06-07 kl. 17:09, skrev Simon Slavin:


On 7 Jun 2017, at 1:49pm, Daniel Polski  wrote:


Ok, have I understood this correctly:

If doing a manual checkpoint with SQLITE_CHECKPOINT_TRUNCATE, that call will 
block for maximum the time set by the busy_timeout while trying to proceed.
If the busy timeout is 0, the call will return immediately if something 
currently is blocking checkpoint progress.
If the busy timeout is set to something > 0, the checkpoint call will retry to 
proceed during the timeout.

Richard answered the part about checkpoints.  In WAL mode, instead of being 
blocked, a reading thread sees the data as it was when the last transaction 
finished.  This is in contrast to the older non-WAL mode, where reading could 
block writing.  However in both modes, one writing thread will block another.

I write about timeouts.  If you do not set a timeout, SQLite immediately treats 
access contention as a fatal error, and returns with SQLITE_BUSY or 
SQLITE_LOCKED.  If you do set a timeout, SQLite will keep attempting access for 
up to that time.  If it eventually gets access it returns with a success result 
code as if there had never been any problem.


Aha, thank you both for the explanations.
I guess one possible reason for the checkpoint to return an error (when 
using a timeout) could be if there is a transaction opened before the 
checkpoint call, which is still using the WAL file when the timeout 
expires..?
Got any more examples which could make it return an error I should be 
aware of?


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

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[Simon Slavin]

On 6 Jun 2017, at 2:17pm, PICCORO McKAY Lenz  wrote:

> how its the status of this work?

The work of parsing comments in the CREATE TABLE command ?  I don’t think 
anyone else thinks this is worth working on.  Discussion in this list has come 
up with many reasons why it’s a poor way to store comments, including

* Difficulty of parsing text which may have CR, LT, tab, comma, etc..
* Impossible to update the comments without DROPping and reCREATEing the table 
because SQLite implements only a few ALTER TABLE commands.
* Documentation restricted to one language.

Here’s a simple version of the best system I ever came up with from working in 
multi-programmer projects, where clear comments were important to letting one 
developer know what another intended.  Comments for a database can be stored in 
the following table in that database:

CREATE TABLE meta_comments (
entityType TEXT COLLATE NOCASE NOT NULL,
theTable TEXT COLLATE NOCASE NOT NULL,
theName TEXT COLLATE NOCASE NOT NULL,
theComment TEXT COLLATE NOCASE NOT NULL,
PRIMARY KEY (entityType, theTable, theName));

Values for "entityType" can be ’schema’,'table','index','trigger','view', and 
anything else you want to document.

If you need multilanguage documentation (required for some countries which work 
to protect a language) add a "language TEXT COLLATE NOCASE NOT NULL" field and 
include it in the primary key.  Ih one use of an early version of this we also 
used a field called "theVersion" to document changes in each entity, though I 
don’t know how sensible that is for most uses.  We also used to use a table 
like this to store commands, though if I was designing that system from scratch 
now I’d use a different table.

I came up with the above structure myself, warrant that it is not encumbered by 
any intellectual property, and dedicate it to the public domain.  Anyone can 
use it for anything they want.

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

Re: [sqlite] Massively multithreaded SQLite queries

[Vikas Aditya]

Hi Andrew,

This is a great use case for SQLite. Did you have to use any special flags or 
settings for SQLite to achieve this e.g. cache size, page size Read only etc?

Thanks,
Vikas


> On Jun 7, 2017, at 10:07 AM, Andrew Brown  
> wrote:
> 
> Wanted to just let you all know that I really appreciated the help you 
> offered when I asked this a few months ago.
> 
> Since then, I've jettisoned the idea of using multiple threads and moved to 
> using multiple processes instead. I have built out an API that accepts http 
> requests for queries, chunks them into deterministic jobs (which improves the 
> probability of a cache hit), which are combined with the operation that needs 
> to be run on the job and hashed, sent via 0mq to the many dbnode processes 
> that are running, where the dbnode checks the cache for the hash in question, 
> and if it does not exist, then queries the Sqlite databases for the result. 
> From there the subqueries are sent back to the coordinator in the API node 
> and combined into the result set for the client.
> 
> It's really fast. It wouldn't be great if I had to write data, but as a data 
> slicer against fixed data, it's pretty slick.
> 
> Just want to thank those who responded and also those who have created and 
> contributed to SQLite as it's a pretty fantastic way to filter through a few 
> terabytes of information - many billions of rows, in mere milliseconds - even 
> more so when parallelized like this.
> 
> 
> 
> 
> 
> From: Andrew Brown
> Sent: Friday, March 3, 2017 12:14 PM
> To: 'sqlite-users@mailinglists.sqlite.org' 
> 
> Subject: Massively multithreaded SQLite queries
> 
> Hello,
> 
> Based on my reading of the documentation it seems like SQLite is a great 
> candidate for cases where you have a large number of threads that only need 
> to read a database simultaneously, in our case for fast data lookup, 
> aggregation, etc. I've been able to generate SQL queries that do this, but 
> once we start running them on a large server with a lot of multithreading 
> going on, I find that we spend a lot of time in __raw_spin_lock - perhaps 
> 75%+ of the time (In one case, 87% of 350 seconds x 72 cores was spent in 
> __raw_spin_lock). This is being run on 64 and 72 core machines, and the more 
> cores I run it on, the slower it ends up going.
> 
> To give a bit more detail, I'm working with dotnet core, have written a 
> custom sqlite wrapper (since the dotnet core one lacks the ability to set 
> connection flags beyond readonly, and doesn't have sqlite_prepare_v2() 
> implemented), and I'm running on linux against a bunch of SQLite files in the 
> 2gb-400gb size range. Individual queries are wicked fast, but once I start 
> spreading the load over all the cores by running simultaneous queries I lose 
> the performance advantage and it actually becomes significantly slower.
> 
> Have tried setting SQLITE_OPEN_NOMUTEX, SQLITE_OPEN_FULLMUTEX. Tried shared 
> cache, read uncommitted. Tried without shared cache, read uncommitted. Tried 
> WAL. If I write a less efficient query, I spend less time in __raw_spin_lock, 
> but of course then it takes longer for the queries themselves to return.
> 
> Any tips to handle massively multithreaded side by side chunked queries on 
> the same database?
> 
> Thank you in advance,
> Andrew Brown
> ___
> 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] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[Warren Young]

On Jun 7, 2017, at 10:37 AM, Stephen Chrzanowski  wrote:
> 
> You can't be 100% certain that GitHub is going to
> be online tomorrow

As well, we have plenty of history showing that we can’t trust the long-term 
availability or trustworthiness of third party hosting services.  Major 
examples are Sourceforge and Google Code in this section of the software 
universe, and we have lots of examples in other areas if those two aren’t 
enough.

> 21st century or not,
> he's not a lemming and doesn't have to jump on the next bandwagon.

The Fossil project was started in 2006, so it’s a 21st century solution, by 
definition. :)

> As for the comment about registration, you need to register to get onto
> GitHub as well.

Wlll, that’s not really the OP’s point, now is it?

The real distinction is that GitHub doesn’t care about your actual identity, 
just that you can be proven to exist somewhere on the Internet in a uniquely 
identifiable fashion.  According to GitHub, there are two “Warren Young” 
entities who both happen to live in my house. :)  One of them more often logs 
in from that house and the other most often logs in from $dayjob’s computers, 
but they’re the same person, and GitHub doesn’t know it.

Fossil, on the other hand, is for projects where all of the developers are 
expected to know each other at some personal level before they join; maybe not 
by face, but certainly by reputation.

There is no “Fork me on Fossil”, on purpose.  Semi-anonymous forks hurt project 
cohesiveness.

In theory, GitHub allows one of the forks to emerge as dominant, pulling in 
changes from more other forks than the others, but more often I see bunches of 
semi-private forks on GitHub, with no hope that the forked versions will ever 
merge changes back upstream.  They might as well be private checkouts with 
local modifications for all the value this sort of forking provides.

In absence of a strong central project, you end up with multiple versions all 
holding the same weight, according to GitHub, with no way for the end user to 
select among them.  I know I’ve personally Googled some project and been 
mislead to someone’s private GitHub mirror of it, simply because GitHub has so 
much Google juice that it often outranks the actual source of the project.  If 
there are multiple mirrors in GitHub, you won’t even know that they’re all 
non-canonical.

The “Fork me on GitHub” model is also fundamentally mismatched with respect to 
projects like Fossil and SQLite where formal license grants (Fossil) or license 
disclaimers (SQLite) are required before changes can be merged into the master 
project.  Repository login grants in such a project are actually just a 
formality gated by the real gatekeeping mechanism, that being the signed 
contributor agreement.

Bottom line, Fossil is perfectly suited to SQLite’s needs, as it should be, 
given that it was created to serve it.

Fossil is also great for other projects of its sort: small to medium sized 
project managed by a small, cohesive group.

Git-style distributed development is better for non-cohesive projects, or for 
those so large that Git’s complexity-bought advantages start to pay off.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Massively multithreaded SQLite queries

[Andrew Brown]

Wanted to just let you all know that I really appreciated the help you offered 
when I asked this a few months ago.

Since then, I've jettisoned the idea of using multiple threads and moved to 
using multiple processes instead. I have built out an API that accepts http 
requests for queries, chunks them into deterministic jobs (which improves the 
probability of a cache hit), which are combined with the operation that needs 
to be run on the job and hashed, sent via 0mq to the many dbnode processes that 
are running, where the dbnode checks the cache for the hash in question, and if 
it does not exist, then queries the Sqlite databases for the result. From there 
the subqueries are sent back to the coordinator in the API node and combined 
into the result set for the client.

It's really fast. It wouldn't be great if I had to write data, but as a data 
slicer against fixed data, it's pretty slick.

Just want to thank those who responded and also those who have created and 
contributed to SQLite as it's a pretty fantastic way to filter through a few 
terabytes of information - many billions of rows, in mere milliseconds - even 
more so when parallelized like this.





From: Andrew Brown
Sent: Friday, March 3, 2017 12:14 PM
To: 'sqlite-users@mailinglists.sqlite.org' 

Subject: Massively multithreaded SQLite queries

Hello,

Based on my reading of the documentation it seems like SQLite is a great 
candidate for cases where you have a large number of threads that only need to 
read a database simultaneously, in our case for fast data lookup, aggregation, 
etc. I've been able to generate SQL queries that do this, but once we start 
running them on a large server with a lot of multithreading going on, I find 
that we spend a lot of time in __raw_spin_lock - perhaps 75%+ of the time (In 
one case, 87% of 350 seconds x 72 cores was spent in __raw_spin_lock). This is 
being run on 64 and 72 core machines, and the more cores I run it on, the 
slower it ends up going.

To give a bit more detail, I'm working with dotnet core, have written a custom 
sqlite wrapper (since the dotnet core one lacks the ability to set connection 
flags beyond readonly, and doesn't have sqlite_prepare_v2() implemented), and 
I'm running on linux against a bunch of SQLite files in the 2gb-400gb size 
range. Individual queries are wicked fast, but once I start spreading the load 
over all the cores by running simultaneous queries I lose the performance 
advantage and it actually becomes significantly slower.

Have tried setting SQLITE_OPEN_NOMUTEX, SQLITE_OPEN_FULLMUTEX. Tried shared 
cache, read uncommitted. Tried without shared cache, read uncommitted. Tried 
WAL. If I write a less efficient query, I spend less time in __raw_spin_lock, 
but of course then it takes longer for the queries themselves to return.

Any tips to handle massively multithreaded side by side chunked queries on the 
same database?

Thank you in advance,
Andrew Brown
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[Stephen Chrzanowski]

Why should Richard and other devs rely on something other than their own
work and source control?  You can't be 100% certain that GitHub is going to
be online tomorrow, which means that a scramble to push code to another
site is going to happen.  You can't be certain that whatever comes after
GitHub and becomes the default place to go for public code repository.

What Richard has put in place is entirely under his control, his management
style, his methodologies, and his implementation.  21st century or not,
he's not a lemming and doesn't have to jump on the next bandwagon.

As for the comment about registration, you need to register to get onto
GitHub as well.  So outside a mail client of my choice, I now have to worry
about a web browser and trust that the remote site is going to be
available, what the provider is going to do with my information.



On Wed, Jun 7, 2017 at 12:17 PM, PICCORO McKAY Lenz 
wrote:

> hello brian, what standars? reading deeply the sqlite site i not see the
> @issue buton@
>
> only see that all contact way must be in the mail list... its a 21 century
> and ID urls its the standar way of integration...
>
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
> 2017-06-07 12:12 GMT-04:00 Brian Curley :
>
> > Not exactly.
> >
> > You're free to extend it yourself and submit it for consideration
> though. I
> > think that you'll just need to adopt the same standards as are in use
> > within the usual enhancements channels.
> >
> > Regards.
> >
> > Brian P Curley
> >
> >
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[Brian Curley]

They're using Fossil as the repository. You'll want to confirm the steps
required, but the main access point is as follow (I believe):

   https://www.sqlite.org/src/login

The main concern is that the functionality that you seek might not scale to
the broader user base. You can always extend it for yourself, and provide a
proof of concept back to the main trunk that may choose to adopt it too.

Otherwise, I think that there were a number of alternative approaches
outlined earlier in the thread. Some of these, such as assigning a
dedicated local database table in addition to sqlite_master, might actually
suffice for your need without impairing users who rely on the program in
the wild.

Regards.

Brian P Curley

On Wed, Jun 7, 2017 at 12:17 PM, PICCORO McKAY Lenz 
wrote:

> hello brian, what standars? reading deeply the sqlite site i not see the
> @issue buton@
>
> only see that all contact way must be in the mail list... its a 21 century
> and ID urls its the standar way of integration...
>
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
> 2017-06-07 12:12 GMT-04:00 Brian Curley :
>
> > Not exactly.
> >
> > You're free to extend it yourself and submit it for consideration
> though. I
> > think that you'll just need to adopt the same standards as are in use
> > within the usual enhancements channels.
> >
> > Regards.
> >
> > Brian P Curley
> >
> >
> >
> > On Wed, Jun 7, 2017 at 12:09 PM, PICCORO McKAY Lenz <
> > mckaygerh...@gmail.com>
> > wrote:
> >
> > > 2017-06-07 9:59 GMT-04:00 Richard Hipp :
> > >
> > > > I would suggest, then, that you grab a copy of the SQLite source
> code,
> > > > put it on github, and start your own fork.  You can then add whatever
> > > > new SQL commands you want.
> > > >
> > > > At this point, your chances of getting us to do your work for you are
> > > > very close to zero.
> > > >
> > > that's not was the topic.. but in any case its a response of the style:
> > > "works for me, doit yourselft"
> > >
> > >
> > > >
> > > > --
> > > > D. Richard Hipp
> > > > d...@sqlite.org
> > > >
> > > ___
> > > 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
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

hello brian, what standars? reading deeply the sqlite site i not see the
@issue buton@

only see that all contact way must be in the mail list... its a 21 century
and ID urls its the standar way of integration...

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-06-07 12:12 GMT-04:00 Brian Curley :

> Not exactly.
>
> You're free to extend it yourself and submit it for consideration though. I
> think that you'll just need to adopt the same standards as are in use
> within the usual enhancements channels.
>
> Regards.
>
> Brian P Curley
>
>
>
> On Wed, Jun 7, 2017 at 12:09 PM, PICCORO McKAY Lenz <
> mckaygerh...@gmail.com>
> wrote:
>
> > 2017-06-07 9:59 GMT-04:00 Richard Hipp :
> >
> > > I would suggest, then, that you grab a copy of the SQLite source code,
> > > put it on github, and start your own fork.  You can then add whatever
> > > new SQL commands you want.
> > >
> > > At this point, your chances of getting us to do your work for you are
> > > very close to zero.
> > >
> > that's not was the topic.. but in any case its a response of the style:
> > "works for me, doit yourselft"
> >
> >
> > >
> > > --
> > > D. Richard Hipp
> > > d...@sqlite.org
> > >
> > ___
> > 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] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[Brian Curley]

Not exactly.

You're free to extend it yourself and submit it for consideration though. I
think that you'll just need to adopt the same standards as are in use
within the usual enhancements channels.

Regards.

Brian P Curley



On Wed, Jun 7, 2017 at 12:09 PM, PICCORO McKAY Lenz 
wrote:

> 2017-06-07 9:59 GMT-04:00 Richard Hipp :
>
> > I would suggest, then, that you grab a copy of the SQLite source code,
> > put it on github, and start your own fork.  You can then add whatever
> > new SQL commands you want.
> >
> > At this point, your chances of getting us to do your work for you are
> > very close to zero.
> >
> that's not was the topic.. but in any case its a response of the style:
> "works for me, doit yourselft"
>
>
> >
> > --
> > D. Richard Hipp
> > d...@sqlite.org
> >
> ___
> 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] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

2017-06-07 9:59 GMT-04:00 Richard Hipp :

> I would suggest, then, that you grab a copy of the SQLite source code,
> put it on github, and start your own fork.  You can then add whatever
> new SQL commands you want.
>
> At this point, your chances of getting us to do your work for you are
> very close to zero.
>
that's not was the topic.. but in any case its a response of the style:
"works for me, doit yourselft"


>
> --
> D. Richard Hipp
> d...@sqlite.org
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] WAL checkpoint starved?

[Simon Slavin]

On 7 Jun 2017, at 1:49pm, Daniel Polski  wrote:

> Ok, have I understood this correctly:
> 
> If doing a manual checkpoint with SQLITE_CHECKPOINT_TRUNCATE, that call will 
> block for maximum the time set by the busy_timeout while trying to proceed.
> If the busy timeout is 0, the call will return immediately if something 
> currently is blocking checkpoint progress.
> If the busy timeout is set to something > 0, the checkpoint call will retry 
> to proceed during the timeout.

Richard answered the part about checkpoints.  In WAL mode, instead of being 
blocked, a reading thread sees the data as it was when the last transaction 
finished.  This is in contrast to the older non-WAL mode, where reading could 
block writing.  However in both modes, one writing thread will block another.

I write about timeouts.  If you do not set a timeout, SQLite immediately treats 
access contention as a fatal error, and returns with SQLITE_BUSY or 
SQLITE_LOCKED.  If you do set a timeout, SQLite will keep attempting access for 
up to that time.  If it eventually gets access it returns with a success result 
code as if there had never been any problem.

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

Re: [sqlite] Minor typo in SQLite documentation

[Richard Hipp]

Fixed.  Thanks.

On 6/6/17, Leon Höpfl  wrote:
> Hello guys,
> First of all, thanks for your great work, I really appreciate working
> with SQLite. I've recently found a minor typo in
> https://sqlite.org/fileformat2.html#sqlite_stat2 in the last row, where
> it states "it is exists, is simply ignored", maybe it should state "if
> it exists, is simply ignored"
> Thanks for your time and work!
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


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

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[Richard Hipp]

On 6/7/17, PICCORO McKAY Lenz  wrote:
> the github issue tracker are more easy to send.. register can made with any
> openid service.. no a complicated email out/of/time system.. its the 21
> century men

I would suggest, then, that you grab a copy of the SQLite source code,
put it on github, and start your own fork.  You can then add whatever
new SQL commands you want.

At this point, your chances of getting us to do your work for you are
very close to zero.

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

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

the github issue tracker are more easy to send.. register can made with any
openid service.. no a complicated email out/of/time system.. its the 21
century men

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-06-07 9:24 GMT-04:00 Stephen Chrzanowski :

> What other way would there be?  Just anonymous "Fix it, add this, do it
> now!" kind of messages?  If you don't register, then anyone can start
> spamming the hell outta the message board.
>
> On Wed, Jun 7, 2017 at 9:15 AM, PICCORO McKAY Lenz  >
> wrote:
>
> > the problem its that for making some noise or request users must
> > register, send email, waith response aproval.. too complicated
> > processs.. that's the reason
> > Lenz McKAY Gerardo (PICCORO)
> > http://qgqlochekone.blogspot.com
> >
> >
> > 2017-06-07 2:16 GMT-04:00 Daniel Kamil Kozar :
> > > Patches are still welcome, I guess. I haven't seen anybody claiming
> > > that this would be done in any way.
> > >
> > > On 6 June 2017 at 15:17, PICCORO McKAY Lenz 
> > wrote:
> > >> how its the status of this work?
> > >>
> > >> a limited implementation will be good!
> > >>
> > >> Lenz McKAY Gerardo (PICCORO)
> > >> http://qgqlochekone.blogspot.com
> > >>
> > >> 2017-03-15 12:24 GMT-04:00 Simon Slavin :
> > >>
> > >>>
> > >>> On 15 Mar 2017, at 4:09pm, Dominique Devienne 
> > wrote:
> > >>>
> > >>> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith 
> wrote:
> > >>> >
> > >>> >> I wonder, sqlite Devs, if a pragma or other adaption (such as the
> > >>> current
> > >>> >> pragma table_info()) or such could produce the same exact data but
> > with
> > >>> an
> > >>> >> added field called "Comment" that simply gives the parsed comment
> > from
> > >>> >> after each column definition (if any) like the above table
> example.
> > This
> > >>> >> would probably be a very small adaptation, be completely backwards
> > >>> >> compatible, doesn't break any standard (since there isn't any) and
> > >>> answer
> > >>> >> the need expressed by this thread and others before it.
> > >>> >
> > >>> > That's one way to solve it, in a mostly BC (Backward Compatible)
> way.
> > >>> > (modulo the output from table_info() changing, which could be
> opt-in
> > to
> > >>> > make it fully BC).
> > >>>
> > >>> Problem is, it requires parsing the CREATE command looking for
> > comments in
> > >>> a certain format.  Notoriously difficult, considering that they can
> > contain
> > >>> CR, LF, tab, and unforeseen Unicode characters.
> > >>>
> > >>> I’m utterly against anything that tries to read C-style comments.
> > >>> Comments are comments.  Computers are meant to ignore them to the
> point
> > >>> that they don’t even know they exist.
> > >>>
> > >>> On the other hand, if we establish a standard for storing comments in
> > >>> database tables — which would require a consistent table name, column
> > >>> names, and values — it might take too much extra time to show those
> > >>> comments as an extra column in the response to PRAGMA tale_info() and
> > >>> similar PRAGMAs.  But I think it’s overkill.  Anyone who would want
> > that
> > >>> would know how to retrieve the information.
> > >>>
> > >>> Simon.
> > >>> ___
> > >>> 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
> > ___
> > 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] WAL checkpoint starved?

[Richard Hipp]

On 6/7/17, Daniel Polski  wrote:
>
>
> Den 2017-06-07 kl. 15:02, skrev Richard Hipp:
>> On 6/7/17, Daniel Polski  wrote:
>>> Does the [TRUNCATE] checkpoint call lock out new requests which might
>>> prohibit
>>> checkpoint progress while waiting for the timeout?
>> It prohibits new writers.  New readers are allowed to proceed.
>>
>>> What will happen with other connections new read/write requests during
>>> the timeout while the checkpointing is running..?
>> Readers proceed normally.  Writers fail with an SQLITE_BUSY errors.
>>
>
> Aha, can those new readers in turn block the checkpointing from proceeding?

No.  Because the new readers will be referencing the most recent
commit, they will not block the checkpoint.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Minor typo in SQLite documentation

[Leon Höpfl]

Hello guys,
First of all, thanks for your great work, I really appreciate working
with SQLite. I've recently found a minor typo in
https://sqlite.org/fileformat2.html#sqlite_stat2 in the last row, where
it states "it is exists, is simply ignored", maybe it should state "if
it exists, is simply ignored"
Thanks for your time and work!

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

Re: [sqlite] WAL checkpoint starved?

[Daniel Polski]

Den 2017-06-07 kl. 15:02, skrev Richard Hipp:

On 6/7/17, Daniel Polski  wrote:

Does the [TRUNCATE] checkpoint call lock out new requests which might prohibit
checkpoint progress while waiting for the timeout?

It prohibits new writers.  New readers are allowed to proceed.


What will happen with other connections new read/write requests during
the timeout while the checkpointing is running..?

Readers proceed normally.  Writers fail with an SQLITE_BUSY errors.



Aha, can those new readers in turn block the checkpointing from proceeding?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[Stephen Chrzanowski]

What other way would there be?  Just anonymous "Fix it, add this, do it
now!" kind of messages?  If you don't register, then anyone can start
spamming the hell outta the message board.

On Wed, Jun 7, 2017 at 9:15 AM, PICCORO McKAY Lenz 
wrote:

> the problem its that for making some noise or request users must
> register, send email, waith response aproval.. too complicated
> processs.. that's the reason
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
>
> 2017-06-07 2:16 GMT-04:00 Daniel Kamil Kozar :
> > Patches are still welcome, I guess. I haven't seen anybody claiming
> > that this would be done in any way.
> >
> > On 6 June 2017 at 15:17, PICCORO McKAY Lenz 
> wrote:
> >> how its the status of this work?
> >>
> >> a limited implementation will be good!
> >>
> >> Lenz McKAY Gerardo (PICCORO)
> >> http://qgqlochekone.blogspot.com
> >>
> >> 2017-03-15 12:24 GMT-04:00 Simon Slavin :
> >>
> >>>
> >>> On 15 Mar 2017, at 4:09pm, Dominique Devienne 
> wrote:
> >>>
> >>> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith  wrote:
> >>> >
> >>> >> I wonder, sqlite Devs, if a pragma or other adaption (such as the
> >>> current
> >>> >> pragma table_info()) or such could produce the same exact data but
> with
> >>> an
> >>> >> added field called "Comment" that simply gives the parsed comment
> from
> >>> >> after each column definition (if any) like the above table example.
> This
> >>> >> would probably be a very small adaptation, be completely backwards
> >>> >> compatible, doesn't break any standard (since there isn't any) and
> >>> answer
> >>> >> the need expressed by this thread and others before it.
> >>> >
> >>> > That's one way to solve it, in a mostly BC (Backward Compatible) way.
> >>> > (modulo the output from table_info() changing, which could be opt-in
> to
> >>> > make it fully BC).
> >>>
> >>> Problem is, it requires parsing the CREATE command looking for
> comments in
> >>> a certain format.  Notoriously difficult, considering that they can
> contain
> >>> CR, LF, tab, and unforeseen Unicode characters.
> >>>
> >>> I’m utterly against anything that tries to read C-style comments.
> >>> Comments are comments.  Computers are meant to ignore them to the point
> >>> that they don’t even know they exist.
> >>>
> >>> On the other hand, if we establish a standard for storing comments in
> >>> database tables — which would require a consistent table name, column
> >>> names, and values — it might take too much extra time to show those
> >>> comments as an extra column in the response to PRAGMA tale_info() and
> >>> similar PRAGMAs.  But I think it’s overkill.  Anyone who would want
> that
> >>> would know how to retrieve the information.
> >>>
> >>> Simon.
> >>> ___
> >>> 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
> ___
> 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] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

the problem its that for making some noise or request users must
register, send email, waith response aproval.. too complicated
processs.. that's the reason
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


2017-06-07 2:16 GMT-04:00 Daniel Kamil Kozar :
> Patches are still welcome, I guess. I haven't seen anybody claiming
> that this would be done in any way.
>
> On 6 June 2017 at 15:17, PICCORO McKAY Lenz  wrote:
>> how its the status of this work?
>>
>> a limited implementation will be good!
>>
>> Lenz McKAY Gerardo (PICCORO)
>> http://qgqlochekone.blogspot.com
>>
>> 2017-03-15 12:24 GMT-04:00 Simon Slavin :
>>
>>>
>>> On 15 Mar 2017, at 4:09pm, Dominique Devienne  wrote:
>>>
>>> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith  wrote:
>>> >
>>> >> I wonder, sqlite Devs, if a pragma or other adaption (such as the
>>> current
>>> >> pragma table_info()) or such could produce the same exact data but with
>>> an
>>> >> added field called "Comment" that simply gives the parsed comment from
>>> >> after each column definition (if any) like the above table example. This
>>> >> would probably be a very small adaptation, be completely backwards
>>> >> compatible, doesn't break any standard (since there isn't any) and
>>> answer
>>> >> the need expressed by this thread and others before it.
>>> >
>>> > That's one way to solve it, in a mostly BC (Backward Compatible) way.
>>> > (modulo the output from table_info() changing, which could be opt-in to
>>> > make it fully BC).
>>>
>>> Problem is, it requires parsing the CREATE command looking for comments in
>>> a certain format.  Notoriously difficult, considering that they can contain
>>> CR, LF, tab, and unforeseen Unicode characters.
>>>
>>> I’m utterly against anything that tries to read C-style comments.
>>> Comments are comments.  Computers are meant to ignore them to the point
>>> that they don’t even know they exist.
>>>
>>> On the other hand, if we establish a standard for storing comments in
>>> database tables — which would require a consistent table name, column
>>> names, and values — it might take too much extra time to show those
>>> comments as an extra column in the response to PRAGMA tale_info() and
>>> similar PRAGMAs.  But I think it’s overkill.  Anyone who would want that
>>> would know how to retrieve the information.
>>>
>>> Simon.
>>> ___
>>> 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
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] WAL checkpoint starved?

[Richard Hipp]

On 6/7/17, Daniel Polski  wrote:
> Does the [TRUNCATE] checkpoint call lock out new requests which might prohibit
> checkpoint progress while waiting for the timeout?

It prohibits new writers.  New readers are allowed to proceed.

> What will happen with other connections new read/write requests during
> the timeout while the checkpointing is running..?

Readers proceed normally.  Writers fail with an SQLITE_BUSY errors.

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

Re: [sqlite] WAL checkpoint starved?

[Daniel Polski]

Den 2017-06-05 kl. 17:48, skrev Simon Slavin:

On 5 Jun 2017, at 1:45pm, Daniel Polski  wrote:


How do I make the checkpointing work like the above documentation describes?

Set a timeout.  Perhaps a very long one (one minute, which is what I use in 
some places).  You can do this two ways:





Please note that the timeout applies only to the connection (and therefore the 
program and the computer) that you set it under.  If you want all connections 
accessing the database to respect the timeout, you have to set it individually 
for all of them.


Ok, have I understood this correctly:

If doing a manual checkpoint with SQLITE_CHECKPOINT_TRUNCATE, that call 
will block for maximum the time set by the busy_timeout while trying to 
proceed.
If the busy timeout is 0, the call will return immediately if something 
currently is blocking checkpoint progress.
If the busy timeout is set to something > 0, the checkpoint call will 
retry to proceed during the timeout.


If the above is correct I got some more questions:
Does the checkpoint call lock out new requests which might prohibit 
checkpoint progress while waiting for the timeout?
What will happen with other connections new read/write requests during 
the timeout while the checkpointing is running..?


Thank you,


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