1/ Oracle RAC's trick: many machines, ONE database on shared storage, every node active and writing. Postgres has never had this in the open. I'm building it — pgrac, RAC's core machinery (Cache Fusion, a global SCN, cross-node MVCC) on PostgreSQL 16. Early, honest, in public. 🧵 #PostgreSQL #database
2/ Why it's hard, one line each:
• a clock every node agrees on (you can't reuse xid/LSN across nodes)
• MVCC across nodes without taxing the node that has no peers
• shipping a dirty page between two memories without losing it
• not corrupting everything when the network splits
3/ Running today, on real code paths: the global SCN clock, dual-track cross-node MVCC, Cache Fusion's data plane, cluster catalog invalidation, the interconnect+heartbeat substrate. Honest caveat: cross-node *behavioral* test coverage is still being built.
4/ Still in progress: live-holder Cache Fusion transfer, full cross-node GES locking, crash recovery + fencing. The anchor under all of it: the --disable-cluster build is binary-identical to upstream PG 16.13 and passes the full 219-test regression suite.
5/ I wrote the four hard problems up, broken down to code level (with links into the real source). Run RAC or any shared-storage cluster? I want your "this breaks under X."
Deep-dive: https://dev.to/sqlrush/rebuilding-oracle-racs-core-machinery-on-postgresql-the-four-problems-that-fight-back-2dhl
Repo (⭐): https://github.com/sqlrush/pgrac
#distributedsystems
Rebuilding Oracle RAC's core machinery on PostgreSQL — the four problems that fight back

pgrac is an attempt to build many of Oracle RAC's core capabilities — shared-everything storage,...

DEV Community