# Keep the settle UPDATE within SQLite's variable ceiling · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/commit/33e4c7624b33217a20929f0639fdcda27fdb6d9c)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

Requested revision: 33e4c7624b33217a20929f0639fdcda27fdb6d9c

Requested commit: 33e4c7624b33217a20929f0639fdcda27fdb6d9c

Commit: 33e4c7624b33217a20929f0639fdcda27fdb6d9c

Tree: 4b6cf8909f14ba7746384b3b506f91af37aae4de

Author: Theo Browne

Committer: Theo Browne

## Message

```
Keep the settle UPDATE within SQLite's variable ceiling

Adding "pending" to the settled states bound them as parameters, costing
two bindings on top of one per thread. `--threads` is capped at 32766 —
SQLite's ceiling — so the documented maximum landed exactly two over and
threw "too many SQL variables", after the target had already been
emptied. Inline the literals; they are internal constants, never input.

The regression test seeds at the cap for real rather than asserting the
statement text, since the property is that no code path adds a binding.
Fixture rows are batched into one transaction and the scale case builds
thread rows only, keeping it near a second.

Caught by Macroscope review.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

```

## Parents

- [8a76bb83cc487b4bbe41ad5707afa3f4bc8e0716](https://git.cafe/pingdotgg/t3code/commit/8a76bb83cc487b4bbe41ad5707afa3f4bc8e0716?format=markdown)

[Source at this commit](https://git.cafe/pingdotgg/t3code/tree/33e4c7624b33217a20929f0639fdcda27fdb6d9c?format=markdown)