Mindkét tranzakció hibátlanul lefutott, negyven dollár mégis eltűnt. Eldobható Postgresen reprodukáltam a lost update-et, a write skew-t és a Read Committed kevert snapshotját – kiderül, mit véd az alapértelmezett izolációs szint, és mit bíz teljes egészében rád.
A LISTEN/NOTIFY a Postgres beépített pub/subja, és tényleg jó. Csakhogy a NOTIFY commitkor egy globális zárat fog, ami libasorba állítja a notifikáló tranzakciókat: 32 kliensnél 24 759 helyett 1708 TPS-t mértem. Megnéztem, kinek van igaza a Recall.ai és a DBOS vitájában, és mit javít a PostgreSQL 19 – és mit nem.
Az actual time egy átlag, nem összeg, a Buffers érték felfelé gyűlik a plan fában, és a sima EXPLAIN ANALYZE nem méri a szerializációt – három valós Postgres 17-es példával.
A FOR UPDATE SKIP LOCKED tíz éve ott van a Postgresben, és simán kiválthatja a Kafkát egy sima háttérmunka-sorhoz – csak épp nem ingyen jön: a valódi ára nem a tábla méretével, hanem a konkurrenciával nő.
A PgBouncer transaction pooling módja gyorsabb, mert a szerveroldali kapcsolat tranzakciónként cserélődik – de emiatt a SET, az advisory lock és a LISTEN/NOTIFY is átszivárogtathat egy teljesen másik kliensre. Hands-on demóval bizonyítva.
A random UUIDv4 primary key évek óta ismert teljesítményprobléma B-fa indexeknél. Az RFC 9562-es UUIDv7 időrendi sorrendbe teszi az azonosítókat, Node.js 26.1-től és PostgreSQL 18-tól natívan is elérhető — nézzük meg, hogyan működik, és mibe kerül.