Loading
Commits on Source 10
-
cznic authoredNathan Herring contributed the Linux OFD lock regression tests in merge request !136, part of the v1.58.0 OFD locking work, and asked to be listed as "Nathan Herring <nherring@google.com>" in #255 (comment 3791205112). Add that line to both AUTHORS and CONTRIBUTORS, in sort order, and replace the bare @technosloth handle in the v1.58.0 CHANGELOG thanks line with his name. Co-Authored-By:
Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019uwmKNHsMYPZgu32fAcTj6
-
cznic authored
Twelve tagged releases had no entry. Each is rebuilt from the git history and the merge requests and issues it cites: v1.38.1, v1.38.2, v1.39.0, v1.40.0, v1.40.1, v1.41.0, v1.42.0 (retracted), v1.42.1, v1.42.2, v1.43.0, v1.44.1 and v1.49.1. A note under the heading marks them as reconstructed on 2026-09-05. Existing entries are untouched. Updates #129 Co-Authored-By:
-
cznic authored
The package documentation lost its changelog section when the release notes moved to CHANGELOG.md on 2026-01-18, and neither the package doc nor the README said where they went. Add a short pointer to both. Updates #129 Co-Authored-By:
-
cznic authored
After the []driver.Value pooling of #226, the &FunctionContext{} passed to Scalar, Step, WindowInverse, WindowValue and Final was the last driver-side heap allocation per invocation: 16 bytes escaping to the heap on every call, about 12% of the allocations left in the #226 reproducer. Fold the context into the pooled per-call object next to the args slice, so one sync.Pool Get/Put serves both, and populate its tls and sqlite3_context fields per call so accessor methods can be added later without touching the trampolines. The vtab Filter and Update paths use the same object with a zero context. Document on FunctionContext and on the callbacks that, like the argument slice, the context is valid only for the duration of the call. BenchmarkUDFArgsAllocation: 5756 -> 4756 allocs/op, 70489 -> 54476 B/op; BenchmarkUDFArgsAllocationVolatile: 3756 -> 2756 allocs/op, 62481 -> 46464 B/op; ns/op unchanged within noise. The #226 reproducer: 25.33M -> 22.35M allocs/op, 553 -> 505 MB/op. TestFunctionContextPerCall checks that every callback receives a populated context. Updates #226 Co-Authored-By:
-
-
cznic authored
Prompted by https://github.com/coderage-labs/spillway/issues/162, which attributed a 103 s query to this driver spilling a temp B-tree in Go. Running that workload here showed no spill (the LIMIT-bounded ephemeral b-tree path never touches a temp file) and a CPU cost of about 2x the same C build, the 103 s being unbounded overlap of periodic polls. The section records what was measured: CPU time per query on linux/amd64 against SQLite 3.53.4 compiled with our options, 2.0x/1.9x/1.3x with modernc.org/libc v1.75.7 and 3.0x/2.2x/1.6x with the transpiled musl mem* routines of earlier libc versions; that the ratios hold under concurrency; and the two practical consequences, indexing what ORDER BY/GROUP BY/WHERE use and bounding the database/sql pool. Co-Authored-By:
-
Ian Chechin authored!137 hands user callbacks a pooled *FunctionContext. TestFunctionContextPerCall checks that the context is populated but not that it is the current invocation's: filling it only when zero and never clearing it on release passes that test while every later callback sees the first invocation's context, and the first accessor to dereference such a context faults in sqlite3_context_db_handle. TestFunctionContextIdentity catches that without dereferencing anything: two functions evaluated in one statement must see two different sqlite3_context values, and on each of two connections held at the same time (so that database/sql cannot hand out one physical connection twice) every callback's tls must be the connection's own, taken through Conn.Raw. It fails under the mutation above and passes on master. TestFunctionContextConcurrent runs the same function on eight connections held at once from their own goroutines, and TestFunctionContextNe...
-
-
cznic authored
Bump modernc.org/libc from v1.75.6 to v1.75.7 and re-vendor lib/ and vec/ from modernc.org/libsqlite3 v1.14.5 and modernc.org/libsqlite_vec v0.5.0, both transpiled against it. lib/ comes out byte-identical: the 19 SQLite 3.53.4 transpiles did not change between libsqlite3 v1.14.4 and v1.14.5, only the libc they link against did. vec/ picks up the libsqlite_vec transpiles regenerated with cc v4.29.7 and ccgo v4.35.2: unreferenced macro constants added, dropped or re-evaluated (CHAR_MAX 255 -> 127 on linux/386, linux/amd64 and linux/loong64, CHAR_MIN dropped there), and one bounds check in _int8_vec_from_value on darwin spelled -128 and INT8_MAX instead of -127-1 and 127. sqlite-vec stays at v0.1.9. The rest of the vec/ diff is undup re-folding those constants between the shared files. make build_all_targets passes for all 20 targets; go test passes on linux/amd64, including the pooled FunctionContext and vec tests under the race detector. Co-Authored-By: -
cznic authored
Date the pending v1.59.0 section 2026-09-15 and add the two entries it was missing: the modernc.org/libc v1.75.7 bump with the re-vendored lib/ and vec/, and what the native libc routines do to the driver-vs-C CPU ratios; and the Performance section doc.go gained in 59ec397b. Co-Authored-By: