OTOH the PolarDB specific changes seem to be contained enough that if you decide to run it in production, you can probably just apply most of the changes from the v11 branch yourself.
But I agree it's not a very good look to code-drop something on a .2 release when there's been 2,5 years of fixes.
Even if the conflicts are minor, it's going to be annoying to try to work it out. If you are hitting a specific crash, there's a good chance you can backport the fix cleanly, but I doubt you can just pull in all of the fixes proactively without some knowledge of the details of the fork.
I haven't really looked at the details... perhaps PolarDB already has many (or all) of the fixes since 11.2. Also I haven't actually tried a merge, I'm just assuming the difficulty based on the number of diffs (and my experience doing minor version merges in the past).
(Disclaimer: I work for Citus Data. Citus takes the approach of a pure extension, which means it works on unmodified Postgres, and minor upgrades typically don't interfere at all.)
CockroachDB seems to be a distributed database system written in Go which has implemented a Postgres query/wire protocol compatibility layer.
PolarDB is a Postgres fork actually using the Postgres codebase and extending it to a distributed database system. Maybe one day they can unfork because it's possible to implement PolarDB on top of Postgres as an extension and/or they contribute/get all their changes into Postgres core.
Also, Postgres 12 introduced pluggable storage, which might help to implement a shared-nothing architecture without huge changes to vanilla Postgres (I haven't looked at how large their delta is)
Citus Data enables scale out, while also being a pure extension. That means you can upgrade Postgres like normal to the latest point release using whatever normal upgrade process you want (e.g. OS packages).
It has worked for a long time without the need for Postgres 12. However, the new APIs introduced in v12 did enable us to offer columnar compression as an option, which complements a lot of scale-out use cases.
But that's also true for e.g. the US and russian presidents, no? Except those actually hold real power.
In practise, most german presidents will just be way too old four years after they leave office to be a viable candidate, and it looks a bit absurd for them to be pushed back into the office, exactly because there's very little real power.
I don't think it's possible for the US president, they are limited to 10 years (two terms + two years if they were vice president and became acting president) which, afaik, is per life-time.
I agree though, it's not an issue, precisely because the German president has historically not acted partisan (even though he's usually a member of a party) and not be involved in day-to-day politics, so it's not too hard to find somebody that everybody can agree on. This may change if the office becomes more politicized, but I doubt we'll see somebody get re-elected after having paused for a term.
That's correct - a US president cannot serve more than two terms. If they were already acting as President for two or more years, they can only be elected to the position once. This was codified in the 22nd Amendment to the US Constitution.
root@pg1:~# LANG=C apt install postgresql-12
Reading package lists... Done
[...]
0 upgraded, 32 newly installed, 0 to remove and 0 not upgraded.
Need to get 59.7 MB of archives.
After this operation, 240 MB of additional disk space will be used.
Do you want to continue? [Y/n] ^C
root@pg1:~# LANG=C apt install postgresql-12 postgresql-12-postgis-3
Reading package lists... Done
[...]
0 upgraded, 105 newly installed, 0 to remove and 0 not upgraded.
Need to get 104 MB of archives.
After this operation, 418 MB of additional disk space will be used.
Do you want to continue? [Y/n]
I think the addition of LLVM for JIT execution of plans added a lot to the Postgres install baseline (at least in distribution packages, you can compile a much leaner postgres yourself).
Due to the way that the LLVM dependency in postgres works, it could be packaged separately from the base postgres server package. The LLVM interfacing code is runtime loaded, and there's no error if "llvmjit.so" is not on the system, even when the server was built with LLVM support. It's basically a packager's choice whether to do so, or not.
