[sqlite] Does PRAGMA synchronous=OFF ensure that no synching is done for the entire session?

I need to know that if I turn of the synchronous that no synching will be done, up to, and including, when the session is closed. I'm asking, because my program just INSERTs once per session, so if a synch gets done when the session closes, that's pretty useless.

Re: [sqlite] Does PRAGMA synchronous=OFF ensure that no synching is done for the entire session?

Simon Slavin wrote: > On 14 Aug 2009, at 5:25pm, Angus March wrote: > > >> I need to know that if I turn of the synchronous that no synching will >> be done, up to, and including, when the session is closed. I'm asking, >> because my program just INSERTs once per

Re: [sqlite] Does PRAGMA synchronous=OFF ensure that no synching is done for the entire session?

Matt Sergeant wrote: > On Fri, 14 Aug 2009 12:33:30 -0400, Angus March wrote: > >> I want my INSERT done right away, I just don't want it to be flushed >> from the filesystem's write-behind cache until the kernel decides, not >> when SQLite decides. >>

Re: [sqlite] Does PRAGMA synchronous=OFF ensure that no synching is done for the entire session?

Matt Sergeant wrote: > On Mon, 17 Aug 2009 10:47:23 -0400, Angus March wrote: > >>> Because yes, that's what synchronous=OFF means. It stops SQLite from >>> issuing fflush calls (effectively). >>> >>> >> Right, and this is i

Re: [sqlite] Does PRAGMA synchronous=OFF ensure that no synching is done for the entire session?

Shane Harrelson wrote: > To the original question though, with PRAGMA synchronous=OFF, SQLite will > NOT do explicit fsync()'s. A exception to this occurs with attached DB's > and a transaction; when the transaction is committed and the master journal > is deleted, SQLite fsyncs the directory

[sqlite] PRAGMA locking_mode could stand a rewrite

For one thing, they shouldn't be using the word "exclusive" to mean two different things. There's "locking_mode=EXCLUSIVE" meaning "permanent" and "exclusive lock" meaning "write lock". At least I think that's what they mean. But my problem is understanding exactly when a lock is released

[sqlite] Copying an open db file

I want to copy a db file while it is still open, and I'm wondering how safe that is. It would go something like this: 1. Lock exclusively with PRAGMA locking_mode=EXCLUSIVE; Many process are accessing the db afterall 2. UPDATE a_table SET a_column=0; 3. After finalizing (I'm using

Re: [sqlite] Copying an open db file

Igor Tandetnik wrote: > Angus March <an...@uducat.com> wrote: > >> I want to copy a db file while it is still open, and I'm wondering how >> safe that is. It would go something like this: >> >> 1. Lock exclusively with PRAGMA locking_mode=EXCLUSIVE; Many

[sqlite] Date range in the WHERE clause

I have a table where I need to record the date of each insert. Sometime later I'll then delete all rows that were inserted more than 90 days ago. Is it possible to do this w/out performing a table scan? ___ sqlite-users mailing list

Re: [sqlite] Date range in the WHERE clause

Igor Tandetnik wrote: > Angus March wrote: > >> I have a table where I need to record the date of each insert. >> Sometime later I'll then delete all rows that were inserted more than >> 90 days ago. Is it possible to do this w/out performing a table scan? >

Re: [sqlite] Date range in the WHERE clause

Igor Tandetnik wrote: > Angus March wrote: > >> Igor Tandetnik wrote: >> >>> Angus March wrote: >>> >>> >>>> I have a table where I need to record the date of each insert. >>>> Sometime later I'll then delete a

[sqlite] Binding parameters to prepared statements

I'm trying to make a prepared statement and bind parameters to it, but the documentation is very confusing. This is the statement I'm trying to prepare: UPDATE 'KEYS' SET 'IVAndKey'=:VVV WHERE "ItemID"=?NNN Where IVAndKey is a BLOB and ItemID is an INTEGER and the primary key for the table. I'm

Re: [sqlite] Binding parameters to prepared statements

t's what I literally had there. I thought you used the literal ?NNN for INTEGER afinity, and :VVV for strings. Like I said, the documentation is very confusing. Even if it had italicized the VVV and the NNN I might have twigged. Thanks. > > Pavel > > On Tue, Aug 25, 2009 at 9:31

Re: [sqlite] Binding parameters to prepared statements

John Elrick wrote: > Angus March wrote: > >> I'm trying to make a prepared statement and bind parameters to it, but >> the documentation is very confusing. This is the statement I'm trying to >> prepare: >> UPDATE 'KEYS' SET 'IVAndKey'=:VVV WHERE "ItemI

Re: [sqlite] Binding parameters to prepared statements

John Elrick wrote: > Angus March wrote: > >> John Elrick wrote: >> >> >>> Angus March wrote: >>> >>> >>> >>>> I'm trying to make a prepared statement and bind parameters to it, but >>>> t

Re: [sqlite] Serious locking/blocking issue

Pavel Ivanov wrote: >> Will sqlite3_unlock_notify() work for this, or do I need to be >> doing something else? >> > > No, sqlite3_unlock_notify() doesn't work for multi-process > applications. For them you should do some retries after delay by > yourself (probably using sqlite3_busy_handler()

Re: [sqlite] Serious locking/blocking issue

Igor Tandetnik wrote: > Angus March <an...@uducat.com> wrote: > >> What should >> the callback that is passed to sqlite3_busy_handler() be doing? >> > > It should be deciding whether to continue waiting for the lock to clear, > or to allow S

[sqlite] blocking when locking

I'm writing this system wherein I want operations performed on the database to block when a lock cannot be achieved, and I'm looking at my options. This system that has multiple processes accessing a single sqlite file with a single database with a single table. I was disappointed to find out

Re: [sqlite] blocking when locking

Pavel Ivanov wrote: > >>To be clear, my idea of blocking is as follows: if one tries to >> achieve a lock, and it is not possible, the request is put into a queue, >> and the caller stops consuming cycles. Locks are then granted (when >> feasible) in the queue in the order that they were

Re: [sqlite] blocking when locking

Pavel Ivanov wrote: >>The kernel grants them: http://www.manpagez.com/man/2/flock . Or I >> might use fcntl(). >> > > That's why I've asked what is different here from what SQLite already > does because SQLite uses fcntl() on database file already. You can try > Then it must use

Re: [sqlite] blocking when locking

Pavel Ivanov wrote: >> Hell if I know why they use fcntl() for locks, and don't even give >> you the option to block. >> > > I think because they need to detect dead locks. BTW, I believe in case > of dead lock even busy_handler will not be called, just SQLITE_BUSY is > returned... > I

Re: [sqlite] blocking when locking

Pavel Ivanov wrote: > >>How does this preclude me from coming up w/my own lock file with >> POSIX locks? If a bunch of process start making incompatible requests on >> a single lock file, then they'll be queued and processed in order. I >> don't see how you can have a deadlock when you have

Re: [sqlite] blocking when locking

Igor Tandetnik wrote: > Angus March <an...@uducat.com> wrote: > >>Yes, I see. So what is key to the problem is that someone tries to >> change their read lock to a write lock. I guess I just thought that >> the kernel that manages fcntl() would have a wa

Re: [sqlite] Why are allowed to keep a text of 3 characters in a field that has been set to 2?

P Kishor wrote: > On Mon, Sep 21, 2009 at 5:10 PM, Guillermo Varona Silupú > wrote: > >> Hi >> In these SQL commands: >> >> CREATE TABLE "test" ("code" char(2)); >> INSERT INTO test (code) VALUES("123") >> >> Why are allowed to keep a text of 3 characters in a field that