Hacker News Reader

Comment by ioltas | Hacker News Reader

Looking at their code tree, this is based on 11.2 (https://www.postgresql.org/docs/11/release-11-2.html): https://github.com/alibaba/PolarDB-for-PostgreSQL/blob/maste...

So this is code from two years ago missing stability fixes from upstream up to 11.12, at short sight.

View on HN

Looks like it, yeah.

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.

See: https://www.citusdata.com/blog/2021/03/06/citus-10-columnar-...

I believe using the extension facilities of Postgres is far superior to a fork in the medium to long term.

(Disclaimer: I work for Citus, and on columnar compression.)

> I work for Citus, and on columnar compression.

:-)

I am waiting for the basic index support for columnar tables !

https://github.com/citusdata/citus/pull/4950

:-)

Are there any stability fixes you have in mind? In my recollection, there is not much instability in PG releases.

IMHO: with the latest fix -> more stable

search for "crash":

https://www.postgresql.org/docs/release/11.3/ ( 11x )

https://www.postgresql.org/docs/release/11.4/ ( 4x )

https://www.postgresql.org/docs/release/11.5/ ( 1x )

https://www.postgresql.org/docs/release/11.6/ ( 3x )

https://www.postgresql.org/docs/release/11.7/ ( 14x )

https://www.postgresql.org/docs/release/11.8/ ( 5x )

https://www.postgresql.org/docs/release/11.9/ ( 6x )

https://www.postgresql.org/docs/release/11.10/ ( 5x )

https://www.postgresql.org/docs/release/11.11/ ( 3x )

https://www.postgresql.org/docs/release/11.12/ ( 5x )

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.

The diffs are non-trivial (EDIT: only included changes in directories where conflicts are most likely to occur):

    $ git log --oneline REL_11_2..REL_11_12 -- src/backend src/include ':!src/backend/po' | wc -l
    536
    $ git diff --stat REL_11_2..REL_11_12 -- src/backend src/include ':!src/backend/po' | tail -1
     352 files changed, 14651 insertions(+), 7078 deletions(-)

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.)

Reply on news.ycombinator.com