Large objects over Fastpath, a drop that can't wedge the engine, and TCP_NODELAY everywhere
Summary: Large objects over Fastpath, a drop that can't wedge the engine, and TCP_NODELAY everywhere (v0.6.0b10).
This release closes two of the oldest gaps a PostgreSQL client could hit.
The PG server now implements the Large Object API the way pgjdbc's
LargeObjectManager (and therefore JDBC Blob/Clob) actually drives it —
the Fastpath sub-protocol dispatching lo_open / loread / lowrite and
friends by their real pg_proc OIDs, backed by chunked sparse storage that
joins the session's transaction. Around it landed the pieces callable
statements need: user-defined functions in FROM position typed by their
declared return type, Describe that derives result shapes without executing
a side-effecting function body, PostgreSQL's void-argument convention for
the JDBC OUT-parameter slot, and plpgsql RAISE. Four pgjdbc test classes
that were previously zeroed — BlobTest, BlobTransactionTest,
CallableStmtTest, CleanupSavepointsWithFastpathTest — now pass in full.
(Correction: this post originally claimed the DateTest date-offset cluster
was cleared at 192/192 — that number came from a bug in the measurement
script, not the server. The real remaining failures are fixed in the next
release's time-zone work.)
On the storage side, dropping a very large collection could livelock the Rust server: the whole row purge ran as one WiredTiger transaction, and once its delete volume exceeded the cache's dirty budget the engine rolled it back for cache pressure and the retry loop re-ran it forever — an eviction storm that survived client disconnects and ignored SIGTERM. Drops are now chunked and two-phase, with a tombstone that makes a crash mid-purge recover cleanly at the next open, on both servers. Both wire servers also now set TCP_NODELAY on every connection, which removes Linux delayed-ACK stalls worth ~40ms per round-trip — one pgjdbc generated-keys batch test went from 41.5 seconds to 0.2. The performance and concurrency reports on secantusdb.com were re-measured from scratch with hardened harnesses, and the Rust server gained a background oplog pruner and a 4G embedded cache default that keep sustained write throughput off the request path.
Document validation you can actually stage, and an admin UI that reaches the rest of the server
Setting validationAction: "warn" on a collection is how you stage a
validator against live traffic — mongod logs the violations and stores the
document anyway. The Python server accepted the option, reported success,
and then rejected the write with code 121 regardless, so the one workflow
the setting exists for was the one it broke. collMod had the same shape
of problem from the other end: it replied ok: 1 to validationAction
and validationLevel and quietly discarded both, leaving callers
convinced they had relaxed enforcement that was still fully armed. Both
are fixed, on every write path, and the Rust server — which already got
this right — is now matched exactly.
The admin UI also stopped hiding features the server has shipped for a
while. Collections can be created with validators and capped options,
modified with collMod, and renamed (across databases, with an optional
dropTarget); custom roles can be created and dropped. The change-stream
page gained the options that make it a real debugging tool: fullDocument
and fullDocumentBeforeChange, all three start points, and a pipeline
filter — plus a Resume from here button on every event, which finally
closes a loop the page had left open by offering a "Copy resume token"
button with nowhere to paste the token.