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 has been
>> set to 2?
>
Igor Tandetnik wrote:
> Angus March 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 way of dealing with
>> t
Igor Tandetnik wrote:
> Angus March wrote:
>
>> 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 beca
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 mul
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
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 fc
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 reques
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 yeste
Igor Tandetnik wrote:
> Angus March 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 SQLite to report an error to the
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()
I was under the impression that when a C API function attempts to get a
lock on the db that it cannot get, it blocks until it can get the lock.
Well it turns out that this isn't true.
Googling for 'sqlite locking block' has directed me to
http://www.sqlite.org/unlock_notify.html, which suggest
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
>>>&
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
ndings will be correct.
>
Oh, I get it! No, those weren't abstract examples, that'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
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 tol
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
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?
>&
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
sqlite-users@sqlite.or
Igor Tandetnik wrote:
> Angus March 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 process
>>
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 t
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
durin
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 that
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 impl
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.
>&g
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
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.
___
26 matches
Mail list logo