worker_threads: compiled pg / mysql2 misbehave on a worker agent (hang, setBuffer TypeError, wrong param value, cross-agent socket error)

[proggeramlug]

Found while validating #11335 and #11336 on perrymaster (Linux x86_64) against a private PostgreSQL 16.15 and MySQL 8.0.46. The oracle is Node 26.5.1.

When a compiled database driver runs on a worker_threads agent, it misbehaves intermittently. On the main thread, the same code matches Node.

pg 8.23.0 on a worker: reproduces on current main (fcac18a)

The main thread runs a pg Client and Pool session. It then starts a Worker whose entry file does:

import pg from "pg";
import { parentPort } from "node:worker_threads";
const c = new pg.Client({ host: "127.0.0.1", port: 45432, user: "perry_trust", password: "x", database: "perry_test" });
await c.connect();
const r = await c.query("SELECT count(*)::int AS c, $1::text AS who FROM l3_items", ["worker"]);
parentPort?.postMessage(`rows=${r.rows[0].c} who=${r.rows[0].who}`);
await c.end();

There are two failure modes, both intermittent:

• Hang: the worker never posts its message (timeout 20). This happened in 2 of 12 runs on main fcac18a, compiled with PERRY_NO_AUTO_OPTIMIZE=1.
• TypeError: Cannot read properties of undefined (reading 'setBuffer'). This happened in 5 of 6 runs on the lane-L3 builds used for compile: drop the dead pg / mysql2 async-runtime rule; pg / mysql2 programs link no tokio (tokio lane L3) #11331.

Node passes every run. trust auth was used so that #11336 is not involved.

mysql2 3.24.4 on a worker: needs the #11335 fix to get this far

With the same program shape, using mysql2/promise createConnection plus execute("SELECT COUNT(*) AS c, ? AS who FROM l3_items", ["worker"]):

• Wrong value: the worker sometimes reads the parameter back as a number, for example who=392487629690468100 instead of who=worker. Node never does.
• Error after worker.terminate(): the main thread fails with TypeError: Cannot read properties of undefined (reading 'removeAllListeners') at BaseConnection._handleFatalError ← BaseConnection._handleNetworkError. This looks like a socket error from the worker's connection being delivered on the main agent.

Not investigated

I have not reduced either failure yet. Both look like events or values crossing agents. The full probe (probe_pg.ts / probe_mysql.ts plus their worker files) is available on request.