Add the TPC-C driver with HammerDB procedures and a statement form

[tamnd]

Part of #1.

What changes

• machines/install/hammerdb.sh installs HammerDB 6.0 from the pin, checks its sha256 and checks that the PostgreSQL library loads. machines/install/tpcc-roles.sh [CLUSTER] makes the role hammerdb, writes a random password to /etc/rupg-bench/tpcc.pass (root, mode 0600) and allows the roles hammerdb and tpcc with a password on the Unix socket. HammerDB logs in with a password, so these run first.
• src/tpcc.rs and rupg-bench tpcc are the TPC-C driver of spec/20 §20.8. The step build drops the database tpcc and builds --warehouses with HammerDB. The step procedures runs HammerDB TPROC-C with its stored procedures. The step statements runs a driver in the harness on the same schema, because HammerDB has no form with plain statements for PostgreSQL.
• In the statement form, each terminal has its own connection and sends prepared statements, so a New-Order makes 5 + 2n round trips. The items are sorted, 1 percent of New-Orders roll back on an unused item, and a serialization failure or deadlock is retried. The mix is the HammerDB mix with no keying or think time.
• Each run has a ramp of --rampup minutes and counts --duration minutes for each count of --vu and each value of --sync. NOPM is the change of sum(d_next_o_id) over the counted minutes. The server cgroup is measured over the same minutes, with the idle base first. Each row has NOPM per core, the server CPU and the device write bytes for each New-Order, memory.peak, the latency quantiles of each transaction (statements) or the HammerDB time profile (procedures), and the sync bound 0.45 x 60 x T / s with the fdatasync p50 next to the data directory.
• The consistency conditions 1 to 4 of clause 3.3.2 are checked before the runs and after each run. A failure makes the command fail. The step check only checks them.
• The HammerDB log prints the password, so the driver writes ******** in its place in the log and in the result. The password is never on a command line: the HammerDB script reads the file, and psql gets it in PGPASSWORD.
• rupg-bench fixed-set --out DIR writes the YCSB and TPC-C parts of the fixed set of spec/21 §21.14: ycsb/read1000.sql with 1,000 point reads of scrambled zipfian keys, and tpcc/neword100.sql with 100 New-Orders in plain statements.
• rupg-bench instructions now gives the query to psql on its standard input, not with -c. The set of 100 New-Orders is 432,299 bytes, which is over the limit of 128 KiB that Linux sets on one argument. psql now sends each statement as its own message, as a driver does. For a set of one statement, such as a ClickBench or TPC-H query, the server gets the same message as before. --password-file gives psql a password.
• reports/2026-10-07/b41f7e63-server3-* are the reports of the smoke runs below. Their names and their first line mark them as smoke runs.
• The README explains the commands.

Test

srvtest passed on server3: clippy is clean and 61 tests pass. The new tests cover NURand and the last names, the money and array values, the HammerDB scripts and the parsing of its output and time profile, and the 5 + 2n statements of each New-Order of the fixed set.

Smoke runs on server3, 7 October 2026, 13:20 to 13:36 UTC. These are not baselines. server3 is a shared machine with 8 cores, and its load average was 63 at the start. The server is the cluster 19/ycsb on port 5433, PostgreSQL REL_19_STABLE at 7d3d2db7 (19beta4). The script ran with RUPG_BENCH_COMMIT=b41f7e63, the commit of this branch before the rebase:

rupg-bench tpcc --unit postgresql@19-ycsb --port 5433 --hammerdb /root/work/rupg-bench-opt/hammerdb --work /root/work/tpcc/work2 --warehouses 2 --vu 4 --rampup 1 --duration 1 --sync on,off --smoke --report /root/work/tpcc/reports2 --machine server3

The build of 2 warehouses took 298.9 s, and the fdatasync p50 was 1674.7 µs.

Form	synchronous_commit	NOPM	TPM	NOPM per core	Server CPU per New-Order	Write bytes per New-Order	Sync bound	Failed conditions
procedures	on	2,069	4,726	259	8,084 µs	56,912	64,491	0
statements	on	1,094	2,404	137	11,310 µs	59,465	64,491	0
procedures	off	3,770	8,575	471	6,172 µs	48,765	none	0
statements	off	1,109	2,449	139	10,920 µs	35,351	none	0

The statement form had 0 errors and 0 retries. With 4 terminals and 1 counted minute these numbers only show that both forms run and pass the checks.

Then the same script counted the instructions of the two new parts of the fixed set, on the YCSB table of 100,000 rows in the database bench and on the TPC-C database that the build made:

rupg-bench fixed-set --out /root/work/fixed2
rupg-bench instructions --queries /root/work/fixed2/ycsb --set ycsb --engine postgresql --unit postgresql@19-ycsb --conn "host=/var/run/postgresql port=5433 user=bench dbname=bench" --smoke --report ...
rupg-bench instructions --queries /root/work/fixed2/tpcc --set tpcc --engine postgresql --unit postgresql@19-ycsb --conn "host=/var/run/postgresql port=5433 user=tpcc dbname=tpcc" --password-file /etc/rupg-bench/tpcc.pass --smoke --report ...
rupg-bench tpcc --unit postgresql@19-ycsb --port 5433 ... --steps check --smoke

Set	Net instructions	Runs	Base (SELECT 1)
1,000 YCSB point reads	197,406,645	830,706,694, 206,231,527, 238,045,194	8,824,882
100 TPC-C New-Orders	870,376,156	956,960,680, 918,670,439, 917,434,801	47,058,645

The TPC-C base is higher because the role tpcc logs in with a SCRAM password. Each run of the New-Order set adds 100 orders, and the check after the three runs found 0 failed conditions. The first YCSB run is 4 times the others on this shared machine, so these counts are not a ratchet.

The check finds a broken database. At 13:17 UTC, with a build of this branch from a few minutes before the commit, I ran UPDATE warehouse SET w_ytd = w_ytd + 1 WHERE w_id = 1 in tpcc. Then rupg-bench tpcc ... --steps check printed conditions 1 to 4, 1 failures and failed with before the runs: 1 units fail the consistency conditions. After the reverse update, the same command passed with 0 failures.

Differences from the spec and from TPC-C.

• spec/20 §20.8 names HammerDB for both forms, but HammerDB 6.0 has only stored procedures for PostgreSQL. The statement form is the driver of this PR.
• The HammerDB procedure neword does not roll back on the unused item 100001. It commits the order with order lines that have a NULL amount. The statement form rolls back, as clause 2.4.2.3 says.
• The harness reports the device write bytes for each New-Order, not the write amplification of doc 19 §19.10.2.

With this PR the four parts of the fixed set of spec/21 §21.14 run on server3: ClickBench on 1,000,000 rows (#15), TPC-H at SF0.1 (#16), and the YCSB and TPC-C sets here. So this PR completes the instruction runner line of #1. ratchet.toml stays empty until a dedicated runner exists. The TPC-C baseline line stays open because it needs the oltp machine.