Loading
Commits on Source 19
-
cznic authoredThe v1.61.0 attest job failed its own verification. make vendor-check had stamped the working tree's vendor.json again with the image's go1.27.1; its diff check ignores that field, as intended, but attest -observe then read the working tree and recorded that copy, while attest -verify compares the document with the committed vendor.json the proxy serves, which records go1.27.2. The document is specified to carry the maintainer's stamp. -observe now reads vendor.json with git show from the commit the document names, and vendor-check checks the committed vendor.json out again on success, so the tree is left as committed. The attestgen tests commit vendor.json in their fixture and cover a tree stamped with another Go and a commit without the file. VERIFYING.md and the CHANGELOG record that v1.61.0 has no provenance document. Co-Authored-By:Claude Fable 5.1 <noreply@anthropic.com>
-
cznic authored
Commit ran COMMIT with context.Background, so a commit blocked by a reader's SHARED lock in rollback-journal mode waited the full busy_timeout whatever the context given to BeginTx said, and Rows.Next and Rows.Close stepped and finalized without any context: the step that finishes an autocommit INSERT ... RETURNING commits it, and so does finalizing or resetting such a statement after its first row, which is what Row.Scan does for QueryRowContext(ctx, "INSERT ... RETURNING id"). With busy_timeout 2000 each took 2 s past a 100 ms deadline. The transaction keeps the context BeginTx was given and Commit waits with it: database/sql documents that context as in use until the transaction is committed or rolled back, and rolls the transaction back itself when it ends before Commit; a wait ended this way fails the COMMIT, which Commit already answers with a ROLLBACK. The rows keep the query's context and Next and Close wait with it through a new conn.withWaitCtx, which sets the connection's waitCtx and the driver's busy handler for the duration of the step, finalize or reset, and reports a failure once the context is done as the context's error. Only the waits watch the context: a step or a commit that is not waiting for a lock is not interrupted, and a call whose context has no deadline or cancellation is unchanged. Rollback keeps running without a context, as database/sql calls it to clean up once the BeginTx context is done. Resolves #263, thanks SirLouen for the report and the reproducer. Co-Authored-By:
-
Ian Chechin authoredSQLite's VFS contract for a read that runs past the end of the file is the return code SQLITE_IOERR_SHORT_READ and a zeroed unread tail. The three read tests go through SQL, and none of them reaches that branch of vfsRead with an assertion on its result: all three pass when vfsRead returns SQLITE_IOERR_READ there, and when it leaves the tail as it was. TestVFSReadEOF now also calls vfsRead directly for 512 bytes of which the file holds the last 100, and checks the return code, the bytes read and the zeroed tail. Each of the two changes above makes it fail.
-
Ian Chechin authored
The draft of 21 September, brought up to v1.60.0 as the working sheet behind SECURITY.md's scope. Four surfaces: the connection string, the connection lifecycle, the page cache binding and the VFS bridge. Five positions, from who writes the DSN to another user of the same process. Each row names what is supplied, the code it reaches, what goes wrong if that code is wrong, and its status: fixed or documented with the commit, held with where the code keeps it, struck with the reason, out of scope by SECURITY.md, or open with what is missing. Three rows are new, the defects found next to the draft's rows: the interrupt on its own TLS, the vec import that rules out RegisterPageCache, and the 32-bit handle wrap. One row remains open: no fuzz target drives the page cache Truncate and Rekey paths. SECURITY.md and CLAUDE.md point to it.
-
Ian Chechin authored
vfsOpen set its out-flags to int32(os.O_RDONLY), which is 0, while SQLite reads them for SQLITE_OPEN_READONLY, so a database opened through a VFS made by New was writable as far as SQLite knew. vfsio has no xWrite, xTruncate or xSync. An UPDATE failed with SQLITE_NOMEM from the journal open; after PRAGMA journal_mode=OFF the same UPDATE went to the missing xWrite and the process panicked with a nil pointer dereference, from SQL text alone. The out-flags now carry SQLITE_OPEN_READONLY, and every write fails with SQLITE_READONLY. TestVFSWriteRefused runs UPDATE and DELETE with the journal on and off and checks the table afterwards; on the old flags it fails at the first UPDATE with SQLITE_NOMEM. The vfs tests pass under -race, and as GOARCH=386 and amd64 on linux.
-
Ian Chechin authored
-
Ian Chechin authored
-
Ian Chechin authored
Found after the sheet was drafted, in the same v1.60.0 code; fixed by merge request !145.
-
cznic authored
vfs: report files opened through vfs.New as read-only to SQLite CHANGELOG.md: credit the merge request and name the WAL close path the fix also covers. See merge request !145 Co-Authored-By:
-
cznic authored
THREAT-MODEL.md: the driver's threat model; assert the short read in TestVFSReadEOF CHANGELOG.md: credit the merge request. See merge request !146 Co-Authored-By:
-
cznic authored
The sqlite3_vfs that New registers wired the vfsDelete transpiled from vfs.c as its xDelete, a ccgo stub that printed "TODO vfsDelete:475:" and aborted the process, and whose code after the abort would have unlinked the path on the host file system, relative to the working directory. SQLite calls xDelete without consulting the read-only flag that vfsOpen reports since !145, to remove a journal it believes it no longer needs: when PRAGMA journal_mode leaves PERSIST or TRUNCATE, so from SQL text alone, and in hasHotJournal on the first read of a 0-byte database that has a -journal file next to it in the served file system. New now installs vfsDeleteReadOnly, which deletes nothing and fails with SQLITE_IOERR_DELETE; both callers tolerate the failure, so PRAGMA journal_mode reports the new mode and the empty database reads as empty. The io methods table also gets xWrite, xTruncate and xSync, which were nil: SQLite consults the read-only flag before every write path, so they are not expected to run, but a nil method is a crash and a method that fails is an error. xWrite and xTruncate answer SQLITE_READONLY, xSync SQLITE_OK. TestVFSDeleteRefused runs both xDelete callers against decoy files in the working directory and the served journal; TestVFSWALReadOnlyClose covers a path !145 also fixed, closing a WAL database shipped with its -wal file, which checkpointed through the missing xWrite. THREAT-MODEL.md gets the row and the WAL note, and two corrections: the shorthand keys validated before the apply phase include _synchronous and _query_only, and BenchmarkPoolEvictionChurn does reach Rekey through SQL. Found while reviewing !145. Co-Authored-By:
-
Roman authored
Since SQLite 3.54, whereLoopOutputAdjust marks a "col = ?" term of a join or an ORDER BY query as plan-sensitive: rebinding it to or from 0 or 1 should re-prepare the statement. The bind functions apply that rule per value, but sqlite3_clear_bindings expires the statement whenever such a parameter exists. The driver clears the bindings after every execution of a cached statement, so each execution parsed and planned it again, which doubles the cost of a simple join. Unbind each parameter with sqlite3_bind_null instead. It drops the references to the bound buffers just the same and expires the statement only when SQLite means it to. Every caller has already reset the statement, as bind_null requires. Add Roman Khafizianov to AUTHORS and CONTRIBUTORS. Fixes #264.
-
cznic authored
stmt.go, reprepare_test.go: stop re-preparing cached statements on each run CHANGELOG.md gets the entry with the credit. See merge request !147 Co-Authored-By:
-
cznic authored
!147 replaced sqlite3_clear_bindings, which since SQLite 3.54 expires any statement with a plan-sensitive parameter, with sqlite3_bind_null on every parameter after each execution of a cached statement. Two costs remained, measured on the reporter's program and on BenchmarkBindManyParameters: a parameter bound to 0 or 1 still re-prepared the statement on every run, because SQLite treats the change from the NULL the unbinding left to a small integer as a reason to plan again, and the unbinding itself cost about 40 ns per parameter and execution, 30 to 37 percent on a multi-row INSERT with thousands of parameters. bind now records, next to each C buffer it allocates for a text or blob argument, the index of the parameter it bound it to, and clearBindings unbinds only those. Integers, floats and NULLs stay bound: they hold no memory the driver owns, nothing in the driver reads a bound value, and bind refuses to run with an argument missing, so every step follows a full rebind. bind also unbinds what it bound when it fails midway, so no parameter points into a freed buffer. rows carries the list to Close. TestCachedStmtNotRepreparedSmallInt runs the statements of TestCachedStmtNotReprepared with 0 and 1; TestCachedStmtTextUnbound checks through sqlite3_expanded_sql that a text parameter reads NULL after every execution while an integer one keeps its value. Updates #264. Co-Authored-By:
-
cznic authored
The section header carries the release date. Co-Authored-By:
-
cznic authored
Limit type-switched on the driver's own *conn, so a driver.Connector that wraps the connections NewConnector opens, as its documentation suggests, could not use it: "unexpected driverConn type". Limit now unwraps the value Conn.Raw hands it for as long as it implements interface{ Unwrap() driver.Conn }, the convention wrappers in the wild use since Go declined one in the standard library; a wrapper without the method fails as before, with the same text. It was the only helper in the package to type-switch on the concrete connection. The NewConnector documentation now also lists the optional interfaces a wrapper must forward, since one that only embeds driver.Conn hides them and database/sql then falls back to the context-free methods. Verified: go test -run 'TestLimit|TestConnector', go vet -unsafeptr=false, staticcheck and golint add no findings. Reported in https://github.com/modernc-org/sqlite/issues/11. Co-Authored-By: -
cznic authored
Re-vendor lib/ from modernc.org/libsqlite3 v1.16.0 and vec/ from modernc.org/libsqlite_vec v0.8.0, both generated with ccgo/v4 v4.38.1 against libc v1.80.1, which go.mod now pins. SQLite stays 3.54.1 and sqlite-vec v0.1.9. lib/ now also carries the modernc_fdatasync() switch. illumos/amd64 joins the vendor tool's target lists, make build_all_targets, builder.json's test set, doc.go's platform table and the GOOS build lines of rulimit.go, vec_test.go and vec/patches.go. vfs/vfs_illumos_amd64.go is a native transpile of vfs/c/vfs.c, made on the OmniOS builder per vfs/Makefile's editor recipe against the SQLite 3.54.1 headers. ccgo/v4 v4.38.1 prefixes struct fields with F by default, but vfs/patches.go uses the unprefixed names, so the recipe now passes --prefix-field "" (an empty value given as "--prefix-field=" is rejected). vfs/c/vfs.c: sqlite3_fsFS allocated the VFS with sqlite3_malloc, but vfs/patches.go frees it with libc.Xfree. Every earlier transpile had been adjusted to libc.Xmalloc by hand, so the faithful illumos one crashed in FS.Close (TestVFS). The C source now calls malloc, matching both. make sbom for the dependency change. CLAUDE.md and IRP.md count 21 targets. CHANGELOG: the open section becomes v1.62.0. Updates #210 Co-Authored-By:
-
cznic authored
Fdatasync(on) selects which system call the library commits with, through modernc_fdatasync() in the transpiled library; FdatasyncEnabled reports the setting; ErrFdatasyncUnavailable covers macOS and Windows, where the library never calls fdatasync. Off by default, so nothing changes without opting in. Updates https://github.com/modernc-org/sqlite/issues/10. lib/ carries modernc_fdatasync() since the previous commit re-vendored it from modernc.org/libsqlite3 v1.16.0; the switch is honored on illumos too. Co-Authored-By:
-
cznic authored
The section header carries the release date. Co-Authored-By: