| Comment: | Keep blob.Load's query text, which read-count tests match on |
|---|---|
| Timelines: | family | ancestors | main | trunk | feat/chunked-blobs |
| Files: | files | file ages | folders |
| SHA3-256: |
9e4f80b2df2c7851107cbe5448651ef3 |
| User & Date: | [email protected] on 2026-10-28 22:58:52.000 |
| Other Links: | branch diff | manifest | tags |
|
2026-10-28
| ||
| 22:58 | Keep blob.Load's query text, which read-count tests match on leaf check-in: 9e4f80b2df user: [email protected] tags: feat/chunked-blobs, main, trunk | |
| 22:52 |
Record chunked length in blob.content and verify parts on read
Review of the chunked-blob change found a missing last part read back short with no error, and a chunked write outside a transaction could leave a torn row that looked held. A chunked row now keeps its stored length in blob.content as an INTEGER. Reads check the parts run unbroken from seq 0, are full-sized but for the last, and add up to that length; anything else is ErrPartsCorrupt, and a NULL content is no longer mistaken for a chunked one. StoredLenSQL reads the length off the row and needs no schema probe. Chunked writes, and the phantom fill around them, run in a savepoint of the caller's transaction or a transaction of their own, so a failed part leaves nothing behind. A value needing more than 4096 parts is an error, not a panic, since stored values can come from peers. The cone and sparse local payload reads use ReadStoredExact, which loads a value only at the length already budgeted for. MaxValueBytes is documented as process-wide, and unversioned content as not chunked. check-in: 0fc4d176c3 user: [email protected] tags: feat/chunked-blobs, main, trunk | |