Parity with fly.io's postgres-flex, possible fork and upstream

[pragmaticanon]

Fly.io's postgres service is currently open source. To achieve high availability with OrioleDB, we need to implement many features already present in postgres-flex. I think forking it to add OrioleDB functionality as an extension (similar to how TimescaleDB is integrated) and implementing backups via Tigris and then potentially upstreaming it later could be a good idea. Interested in your thoughts on this strategy versus selectively implementing features from postgres-flex into the current repo.

[kiwicopple]

I suspect that postgres-flex is using Postgres' built-in replication system (using repmgr)

whereas what we want in this repo is to leverage Tigris for data replication:

This should (in theory) provide a simpler implementation, because if your primary fails, you just kill it and start a new one (vs doing a full fail-over from the primary to the replica). In practice there are a few other considerations to worry about (startup time, reading data to the primary) the main goal is to get an MVP up with Tigris first. We should be able to get this working without the assistance of any other extension like repmgr

That said: you're 100% correct - there could be a lot of implementation we can pluck from postgres-flex. It's useful to have it as prior art

[pragmaticanon]

Correct me if I am wrong but oriole's s3 implementation doesn't currently have a way to make use of same buckets for replica right? So wouldn't that mean you would still need something like repmgr to do the replication? We would actually be replacing barman's role in postgres-flex right?

[kiwicopple]

oriole's s3 implementation doesn't currently have a way to make use of same buckets for replica right

It actually can point to the same bucket, but it's risky because if the replica writes to this bucket it will corrupt the data (so it really needs to be in read-only mode