dolthub / dolthub/doltlite

Implicit-rowid INSERT returns SQLITE_FULL instead of the random-rowid fallback

Closed
#2,908 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
268
Forks
18
Avg merge
2h 26m
Merged PRs (30d)
454

Description

Found in a full-repo review at `0ba280f06f`.

An implicit-rowid `INSERT` into a plain (non-`AUTOINCREMENT`) table returns `SQLITE_FULL` where stock falls back to the random-rowid search documented at R-07677-41881.

```sql
CREATE TABLE t(id INTEGER PRIMARY KEY, v TEXT);
INSERT INTO t VALUES(9223372036854775807,'max');
INSERT INTO t(v) VALUES('next');
SELECT 'rows', count(*) FROM t;
-- EXPECTED (stock 3.54.0): rows|2
-- GOT: Error: database or disk is full (rows|1)
```

## Cause

`rowidTableUsesSharedSeq` (`src/insert.c:413`, used at `:437`) routes every prolly-backed rowid table through the AUTOINCREMENT codegen, so `OP_NewRowid` is emitted with `P3!=0`:

```
doltlite: NewRowid 0 5 2
stock: NewRowid 0 1 0
```

That takes the AUTOINCREMENT branch at `src/vdbe.c:6249`, which returns `SQLITE_FULL` when `pC->useRandomRowid` is set instead of performing the random-candidate search that non-AUTOINCREMENT tables get.

This is a consequence of the shared-counter design from #2684 / #2689, where every prolly rowid table (including keyless) allocates from the branch-shared counter so that ids do not collide across branches. Behaving like an `AUTOINCREMENT` table at the ceiling is arguably consistent with that model — stock `AUTOINCREMENT` tables also return `SQLITE_FULL` here — but it is a divergence from stock for a table the user did not declare `AUTOINCREMENT`, and it is undocumented.

## Fix

Either restore the random-rowid fallback for tables without `AUTOINCREMENT` (allocating a free id below the ceiling rather than continuing the counter), or accept the divergence and record it: a row in `test/sqlite_compatibility_contract.tsv` plus a line in `doc/doltlite/sqlite-compatibility.md`, alongside the existing no-reuse note from #2684.

Low severity — it needs a row at int64 max — but it is currently silent and unrecorded.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with `rowidTableUsesSharedSeq` in `src/insert.c` and the `OP_NewRowid` handling at `src/vdbe.c:6249`; compare the emitted opcode with stock SQLite as described. Decide whether to restore random-rowid fallback or document the divergence. If documenting, update `test/sqlite_compatibility_contract.tsv` and `doc/doltlite/sqlite-compatibility.md`; done means the chosen behavior is tested and recorded.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, sqlite
Domain
databases
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
63/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.