PostgreSQL High Availability Solutions – Part 1: Jepsen Test and Patroni

Re:PostgreSQL High Availability Solutions – Part 1: Jepsen T... by atombender on Tuesday December 10, 2024 @06:10AM (#42375746)

I was referring to the effort by the developers to keep the forked codebase itself up to date with mainline. Isn't that the main hurdle?

My understanding is that you are patching a lot of core Postgres code rather than providing the functionality through any kind of plugin interface, so every time there is a major Postgres release, "rebasing" on top of it is a large effort.

That, to my knowledge, is why Greenplum fell behind so much. It took them four years to get from 9.6 to 12, and I believe that's where they are today.

[ Parent | on HN ]

Re:PostgreSQL High Availability Solutions – Part 1: Jepsen T... by harisund1990 on Tuesday December 10, 2024 @12:34PM (#42379040)

Cutis is an extension. That's the best you can get by being outside the core db. If you want true distributed architecture then you need to change the QO, DDL, transaction, even query stat components. At which point it ends up being a fork.

Yes, the merges are hard. But pg12 changed lots of fundamental things making it very challenging. Pg15 to pg17 should be much simpler.

[ Parent | on HN ]