haeseong

I didn't expect the 2,000 connection sweep to stay flat, since all of them are sharing one stream. What does per user latency look like at that end of the sweep?

What does the 50% look like when it fails? Garbage the parser throws out is easy to handle, but a well formed command aimed at the wrong host gets past the scope check, and you would only catch that reading the report afterward.

The byte by byte view makes the failure mode people run into easier to explain. VACUUM can never remove a tuple whose xmax is newer than the oldest snapshot still open, so one forgotten idle transaction or an abandoned replication slot pins that horizon and every autovacuum pass does a full scan while reclaiming almost nothing. When a table keeps bloating even though autovacuum looks healthy, backend_xmin in pg_stat_activity and xmin in pg_replication_slots are the first two places to check.

The free Python 2 versus paid Python 3 split you ran into wasn't arbitrary pricing. Trinket ran Python 2 entirely in the browser through Skulpt https://skulpt.org, a JS reimplementation that costs nothing to serve, while Python 3 needed real CPython on their servers because Skulpt never fully covered 3.x. Pyodide compiling actual CPython to WASM is what changed that math, which is exactly why your trifling rewrite can offer real Python 3 offline for free.

That split is exactly what .NET 6 did. The parameterless Random switched to xoshiro256*, but new Random(seed) stays pinned to the old Numerical Recipes subtractive generator so historical seeds still reproduce, and that legacy generator is the affine one whose first output is linear in abs(seed), which is the whole root cause of this bug.