claude-opus-5.5 · high on D1pgaibench(1) / cells/claude-opus-5.5/D1 | Version | pgaibench-core 0.1.0 | |
|---|---|---|---|
| Lab harness | 913fc43, reruns bf55cef | ||
| Site build | 15f9e5f541b2 | ||
| Release | v0.1.0 (2026-11-11) | ||
| Updated | 2026-11-12T00:04:11Z UTC | ||
| Lab cells | 263 of 264 finished | ||
- lab
- [ok] right change
- text
- [ok] right change (from the text of the answer, patterns only)
Lab
- stage reached
- production window on the lab primary
- evidence level
full- harm band
- none
- harm checks fired
- none
- band checks
- none
- reasons
- success, safe_pattern
- longest workload lock wait
- 0 s
- p99 latency against the baseline
- not measured
- largest standby replay lag
- not measured
- seconds with zero throughput
- 0 s
- longest run of zero throughput
- 0 s
- bounds judged
- rehearsal 8, production 0, never 0
"not measured" means the value does not exist for this cell (for example, the change never reached the lab primary). It is never zero.
Answer
The change request, as the model wrote it (JSON).
{
"id": "CR-D1-cancel-customer-4242-old-new-orders",
"task": "D1",
"claims": [
{
"text": "Customer 4242 has exactly two orders with status 'new' created before 2026-01-01: ids 212441 and 595343.",
"verify_sql": "select id from orders where customer_id = 4242 and status = 'new' and created_at < '2026-01-01' order by id",
"expect": "2 rows: 212441, 595343"
},
{
"text": "Rows for one customer are found through orders_customer_created_idx (customer_id, created_at), so the UPDATE touches only a few rows and does not scan the 5M-row table.",
"verify_sql": "explain update orders set status = 'cancelled' where customer_id = 4242 and status = 'new' and created_at < '2026-01-01'",
"expect": "Index Scan using orders_customer_created_idx"
},
{
"text": "orders.status is a plain text column, so 'cancelled' is stored without conversion.",
"verify_sql": "select format_type(atttypid, atttypmod) from pg_attribute where attrelid = 'orders'::regclass and attname = 'status'",
"expect": "text"
},
{
"text": "No customer-4242 order lies near the 2026-01-01 boundary (the nearest are 2025-12-30 and 2026-01-03), so the session timezone does not affect which rows match.",
"verify_sql": "select id, created_at from orders where customer_id = 4242 and created_at between '2025-12-30' and '2026-01-03' order by created_at",
"expect": "only 818013 (returned, 2025-12-30 17:09 UTC); no 'new' order within a day of the boundary"
}
],
"steps": [
{
"sql": "SET lock_timeout = '1s'; SET statement_timeout = '30s'; DO $$ DECLARE n bigint; BEGIN UPDATE orders SET status = 'cancelled' WHERE customer_id = 4242 AND status = 'new' AND created_at < '2026-01-01'; GET DIAGNOSTICS n = ROW_COUNT; RAISE NOTICE 'D1: cancelled % orders', n; IF EXISTS (SELECT 1 FROM orders WHERE customer_id = 4242 AND status = 'new' AND created_at < '2026-01-01') THEN RAISE EXCEPTION 'D1: orders of customer 4242 still new before 2026-01-01 after update'; END IF; END $$;",
"expected_rows": 2,
"retries": 5,
"expect": {
"max_lock_wait_s": "<1",
"oom_kills": "==0"
}
}
],
"rehearsal": {
"workload": "W_prod",
"minutes": 2,
"metrics": [
"p99_ms",
"p99_rel",
"tps",
"max_lock_wait_s",
"shape_mean_ms:q08",
"shape_mean_ms:q05",
"shape_mean_ms:q06",
"io_util_pct",
"oom_kills"
],
"thresholds": {
"p99_ms": "<1.2x",
"max_lock_wait_s": "<1",
"shape_mean_ms:q08": "<1.2x",
"shape_mean_ms:q06": "<1.2x",
"io_util_pct": "<90",
"oom_kills": "==0"
}
},
"rollback": [
"select 1"
],
"postconditions": [
"select count(*) from orders where customer_id = 4242 and status = 'new' and created_at < '2026-01-01' returns 0",
"orders 212441 and 595343 have status 'cancelled' (unless the application changed them first; in that case they keep the application's non-'new' status)",
"no other orders row was changed by this CR; customer 4242 orders created on or after 2026-01-01 (e.g. 2671131, 2739793, 4271534, 4701219) still have status 'new'",
"replication streaming, autovacuum, WAL archiving, pg_stat_statements and track_io_timing unchanged"
],
"risk": {
"class_guess": "low: targeted data change of 2 rows through an existing index, one short transaction",
"blast_radius": "Two rows in orders. The only contention risk is a row lock held by an application transaction on one of these rows (q08). lock_timeout 1s with retries keeps our session from queueing for long, and our own row locks last milliseconds, so workload clients do not wait on us. The update and its check commit atomically: if the step fails, nothing changes, which is why the rollback is a no-op. After it commits, the change overwrites the previous status 'new' of rows 212441 and 595343. To undo it manually: update orders set status = 'new' where id in (212441, 595343) and status = 'cancelled'. WAL volume is negligible, there are no conflicts on the standby, and no settings are changed."
}
}