"Igor Tandetnik" <[EMAIL PROTECTED]> wrote:
> "B V, Phanisekhar" <[EMAIL PROTECTED]> wrote in
> message news:[EMAIL PROTECTED]
> > So is it possible
> > that SQLITE will give an error when attempting to insert a record even
> > if there are free ROWID's?
>
> Yes, in theory. If you have close to 2^63-1 rows, probing at random for
> a ROWID to reuse may just happen to keep hitting occupied ROWIDs. If I
> remember correctly, after a certain number of unsuccessful attemps
> SQLite gives up and returns an error.
You remember correctly. Up to 100 random rowids are attempted.
If no unused rowid is found, SQLITE_FULL is returned.
As an aside, I note that this logic presents some interesting
problems for testing. How does one verify that random rowid
algorithm works and that it really does stop after 100 tries
and return SQLITE_FULL? How does one construct a test that
collides for 100 randomly chosen rowids? We can force the
random-rowid logic to run simply by inserting a row with a
rowid of 9223372036854775807. But how can we get collisions
to happen 100 times in a row without inserting
18446744073709551616 distinct rows?
Our solution to this problem is that we allow the test script
to monkey with the state of the Pseudo-Random Number Generator
(PRNG) that SQLite uses to generate random rowids. On a test
build, we have special APIs that will save the current state
of the PRNG and that will restore the state of the PRNG to its
most recently saved state.
So the test runs like this:
* Create a table and insert rowid=9223372036854775807
* Save the current state of the PRNG
* Loop 101 times:
+ Restore the state of the PRNG
+ Insert a new row with a randomly chosen rowid
Sure enough - the loop fails with an SQLITE_FULL error on the
last iteration.
--
D. Richard Hipp <[EMAIL PROTECTED]>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
