Increase the SQLite row limit to 4 MiB - #7020
Conversation
|
APIError: Invalid Anthropic API Key |
2 similar comments
|
APIError: Invalid Anthropic API Key |
|
APIError: Invalid Anthropic API Key |
|
@joshthoward Bonk workflow failed. Check the logs for details. View workflow run · To retry, trigger Bonk again. |
| // This limit is set higher than what is suggested on sqlite.org/security.html | ||
| // because we want to allow storing values of 1MiB, and we added some extra | ||
| // padding on top of that | ||
| sqlite3_limit(db, SQLITE_LIMIT_LENGTH, 2200000); | ||
| // We use most of the suggested limits from sqlite.org/security.html. Note that sqlite3_limit() | ||
| // does NOT return an error code; it returns the old limit. | ||
| sqlite3_limit(db, SQLITE_LIMIT_LENGTH, 4 * 1024 * 1024); |
There was a problem hiding this comment.
Previously we allowed 10% over our documented limit for padding. I have no idea what padding we're accounting for. In the KV interface, we cared about V8 serialization overheads, but we don't use V8 serialization with SQLite. SQLite itself might have padding that I don't know about it.
I guess we will need to update our documentation to say that it's 4 MB, inclusive of any padding the system may add under the covers? That seems less satisfying.
There was a problem hiding this comment.
I have no idea why we did that TBH. I just did the standard thing of implementing a limit using IEC units and documenting the lower SI unit, since folks don't pay attention to the difference.
There was a problem hiding this comment.
We originally did it because v8 serialization added some extra bytes to a value, so when we advertised a limit of 128 KiB we had to add some cushioning or else trying to store an ArrayBuffer or string of exactly 128 KiB (or very close to 128 KiB) would fail, which is quite frustrating as a user.
I'd imagine the same argument still applies here for the KV interface on sqlite DOs?
5 participants
No description provided.