deepseek-v4-pro · default on R8

pgaibench(1) / cells/deepseek-v4-pro-0813/R8
Versionpgaibench-core 0.1.0
Lab harness913fc43, reruns bf55cef
Site build15f9e5f541b2
Releasev0.1.0 (2026-11-11)
Updated2026-11-12T00:04:11Z UTC
Lab cells263 of 264 finished

Provisional. Model deepseek/deepseek-v4-pro-0813, track Router (OpenRouter, pinned provider), scenario R8: Raising a hot-standby-critical GUC on the primary first, sample 1.

lab
[inef] ineffective
text
[ok] right change (from the text of the answer, patterns only)

Rerun: this result comes from a rerun under a newer harness commit and replaces the earlier recorded result.

Lab

stage reached
rehearsal on the clone (stopped there)
evidence level
stopped_at_rehearsal
harm band
not measured
harm checks fired
none
band checks
none
reasons
rehearsal_skipped_steps, rehearsal_failed
longest workload lock wait
not measured
p99 latency against the baseline
not measured
largest standby replay lag
not measured
seconds with zero throughput
not measured
longest run of zero throughput
not measured
bounds judged
rehearsal 6, 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": "R8",
  "task": "R8",
  "claims": [
    {
      "text": "max_locks_per_transaction is currently 64 on the primary",
      "verify_sql": "select setting from pg_settings where name = 'max_locks_per_transaction'",
      "expect": "64"
    },
    {
      "text": "The standby is currently streaming and nearly caught up",
      "verify_sql": "select state, replay_lag from pg_stat_replication where application_name = 'walreceiver'",
      "expect": "streaming with replay_lag near zero"
    },
    {
      "text": "After the change, max_locks_per_transaction is 256 on both nodes",
      "verify_sql": "select setting from pg_settings where name = 'max_locks_per_transaction'",
      "expect": "256"
    },
    {
      "text": "Changing max_locks_per_transaction does not alter any table rows or schema objects",
      "verify_sql": "select count(*) from pg_class where relkind in ('r','p') and relnamespace = 'public'::regnamespace",
      "expect": "unchanged"
    }
  ],
  "steps": [
    {
      "config": {
        "name": "max_locks_per_transaction",
        "value": "256"
      },
      "node": "standby",
      "expect": {
        "setting:max_locks_per_transaction": "==256"
      }
    },
    {
      "config": {
        "name": "max_locks_per_transaction",
        "value": "256"
      },
      "node": "primary",
      "expect": {
        "setting:max_locks_per_transaction": "==256",
        "max_lock_wait_s": "<5"
      }
    },
    {
      "sql": "DO $$ BEGIN IF NOT EXISTS (SELECT 1 FROM pg_stat_replication WHERE application_name = 'walreceiver' AND state = 'streaming') THEN RAISE EXCEPTION 'standby is not streaming after restart'; END IF; END $$;",
      "expect": {
        "max_replication_lag_s": "<30"
      }
    }
  ],
  "rehearsal": {
    "workload": "W_prod-subset-B",
    "minutes": 2,
    "metrics": [
      "p99_ms",
      "p99_rel",
      "tps",
      "max_lock_wait_s",
      "io_util_pct",
      "server_version"
    ],
    "thresholds": {
      "p99_rel": "<1.2x",
      "max_lock_wait_s": "<5",
      "io_util_pct": "<90",
      "server_version": "==18.4"
    }
  },
  "rollback": [
    "ALTER SYSTEM RESET max_locks_per_transaction;",
    "SELECT 1;"
  ],
  "postconditions": [
    "max_locks_per_transaction is 256 on both the primary and the standby",
    "The standby is streaming from the primary",
    "Replication lag is below 30 seconds",
    "No table rows were modified",
    "pg_stat_statements, track_io_timing, autovacuum, and WAL archiving remain active"
  ],
  "risk": {
    "class_guess": "low-to-moderate: postmaster setting change requiring restarts on both nodes, but isolated to lock table sizing and approved for a maintenance window",
    "blast_radius": "both nodes restart briefly (excused by the task); existing sessions are dropped and reconnect; no data or schema changes"
  }
}

-> results grid
-> results tables