Impact of 'Long Forks' in Neon?
Hi, I was just reading the recent Jepsen report: https://jepsen.io/analyses/amazon-rds-for-postgresql-17.4 - it turns out he stumbled across an issue that has been known for quite a few years described as 'Long Fork' behaviour, and looking at the Postgres mailing list thread on the proposed patch for CSN Snapshots I can see that Neon was already investing energy to improve the situation well before the recent buzz (Heikki works for Neon). It seems that patch won't be included in Postgres 18, unless I'm missing another thread(?)
In the meantime though, does the advice in the AWS response to the Jepsen report hold for Neon also? Specifically "Applications should never rely on the implicit commit ordering of independent concurrent transactions". Or does Neon somehow otherwise ensure that all compute nodes observe the same transaction orderings (even for read-only transactions)?
PostgreSQL Mailing List Archives
CSN snapshots in hot standby
You cannot run queries on a Hot Standby server until the standby has seen a running-xacts record. Furthermore if the …
Amazon Web Services
Understanding transaction visibility in PostgreSQL clusters with re...
On April 29, 2025, Jepsen published a report about transaction visibility behavior in Amazon RDS for PostgreSQL Multi-AZ clusters. We appreciate Jepsen’s thorough analysis and would like to provide additional context about this behavior, which exists both in Amazon RDS and community PostgreSQL. In this post, we dive into the specifics of the i...
2 Replies
eastern-cyan•4mo ago
Yeah, he CSN work didn't make it into v18. I'm hoping to commit it early in the v19 cycle
There's no difference in neon in that regard
All read replicas see the transaction commits in the WAL order, so they will all see the same order. But that order can be different from that of the primary
rival-blackOP•4mo ago
Thank you for the explanations, makes sense. Hope the changes can land okay 🙂