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)?
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
You cannot run queries on a Hot Standby server until the standby has seen a running-xacts record. Furthermore if the …
Amazon Web Services
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...
