On 31 Dec 2018, at 10:44pm, Jesse Rittner wrote:
> Simon Slavin-3 wrote
>
>> it can be long only if you're a bad SQL programmer
>
> To be fair, the query in question might not get run frequently enough to
> warrant the overhead of maintaining an index.
Fair point.
Simon.
Simon Slavin-3 wrote
> it can be long only if you're a bad SQL programmer
To be fair, the query in question might not get run frequently enough to
warrant the overhead of maintaining an index.
--
Sent from: http://sqlite.1065341.n5.nabble.com/
___
On 31 Dec 2018, at 9:10pm, Jesse Rittner wrote:
> Simon Slavin-3 wrote
>
>> You can calculate an "end time" yourself, check it each time you're ready to
>> call sqlite3_step(), and jump straight to sqlite3_finalize() if your time is
>> up.
>
> I'm not familiar with the inner workings of
>I don't think the interrupt call will actually terminate a step that
>is actually being processed, but only mark that no more steps should
>happen. In other words, I don't think SQLite is spending time
>checking a flag to stop in the middle of processing a step to allow the
>processing to
On 12/31/18 4:10 PM, Jesse Rittner wrote:
> Simon Slavin-3 wrote
>> You can calculate an "end time" yourself, check it each time you're ready
>> to call sqlite3_step(), and jump straight to sqlite3_finalize() if your
>> time is up.
> I'm not familiar with the inner workings of sqlite3_step, but if
That is, of course (I forgot the stmt argument to sqlite3_stmt_busy in all the
whizing around):
def interrupt_function(db, stmt, timeout, whizround)
while whizround and !sqlite3_stmt_busy(stmt) /* whizround waiting for
statement to start */
sleep(0.001)
On Monday, 31 December, 2018 13:48, Simon Slavin wrote:
>On 31 Dec 2018, at 8:18pm, Jesse Rittner wrote:
>> I'm trying to write a function to run a query with a timeout. If
>> the timeout expires, the query must stop execution within a "reasonable"
>> amount
>> of time.
>There is no rule
On Monday, 31 December, 2018 13:19, Jesse Rittner
wrote:
>Keith Medcalf wrote
>> What are you trying to accomplish? Perhaps what you really want is
>> a progress callback?
> I'm trying to write a function to run a query with a timeout. If the
> timeout expires, the query must stop execution
Simon Slavin-3 wrote
> You can calculate an "end time" yourself, check it each time you're ready
> to call sqlite3_step(), and jump straight to sqlite3_finalize() if your
> time is up.
I'm not familiar with the inner workings of sqlite3_step, but if that itself
takes time, then I'd like to
On 31 Dec 2018, at 8:18pm, Jesse Rittner wrote:
> I'm trying to write a function to run a query with a timeout. If the timeout
> expires, the query must stop execution within a "reasonable" amount of time.
There is no rule that you must continue to call sqlite3_step() until it runs
out of
Keith Medcalf wrote
> What are you trying to accomplish? Perhaps what you really want is a
> progress callback?
I'm trying to write a function to run a query with a timeout. If the timeout
expires, the query must stop execution within a "reasonable" amount of time.
To use a progress callback, it
>To be clear, is it sqlite3_step returning SQLITE_DONE that marks it
>as "not running", or calling sqlite3_reset/sqlite3_finalize?
Well, "running" means that execution has commenced (the first call to
sqlite3_step has been made on the statement) and the execution has not yet
completed.
To be clear, is it sqlite3_step returning SQLITE_DONE that marks it as "not
running", or calling sqlite3_reset/sqlite3_finalize?
Also, is there any way to mark a statement as "running" other than calling
sqlite_step on it? Otherwise, it sounds like I'll have to wait until after
sqlite3_step gets
"RUNNING" means that the statement is running. When you call sqlite3_prepare,
SQLite3 generates a PROGRAM which will "yield" the results of the execution of
that SQL statement. It looks something like this:
START:
... do stuff ...
LOOP:
... do stuff ...
return a result row (SQLITE_ROW)
Consider the following pseudo-code.
void interrupt_timeout(sqlite3* db, int timeout) {
sleep(timeout);
sqlite3_interrupt(db);
}
int main() {
sqlite3* db = sqlite3_open_v2(...);
sqlite3_stmt* stmt = sqlite3_prepare_v2(db, ...);
...
pthread_create(interrupt_timeout, db,
On 12/31/18, Jesse Rittner wrote:
> I have some questions about multi-thread (as opposed to serialized, see
> https://www.sqlite.org/threadsafe.html) connections.
>
> 1. If I have two multi-thread connections that are using a shared cache, is
> it safe to use those two connections concurrently
I have some questions about multi-thread (as opposed to serialized, see
https://www.sqlite.org/threadsafe.html) connections.
1. If I have two multi-thread connections that are using a shared cache, is
it safe to use those two connections concurrently with each other?
2. Same as (1), but what if
Keith Medcalf wrote
> See also Write Ahead Logging journal mode (WAL) where in the case you
> specified B's operation will succeed even if it is updating a table being
> read by connection A.
Oh, good to know! For anyone who stumbles across this thread in the future,
note that this requires that
On 12/30/2018 02:41 PM, Nicolas Roy-Renaud wrote:
I've been dealing with occasional segfaults on one of my applications
when running a similar query, except even on SQLite 3.26, the safeguard
wouldn't trigger.
Running the SQL query specified in the bug report description from the
tracker
19 matches
Mail list logo
