-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to PostgreSQL 15 #9797
Comments
@ymahajan This will also enable creating foreign keys referencing partitioned tables with other improvements for copy, partition join, etc available from PG12 onwards. A few customers have been requesting this feature. |
Do you have a strategy for keeping up with upstream PostgreSQL? I admit that I have not looked into your forked version in detail, so I don't know how feasible it would be. But wouldn't it make sense to refactor the main PostgreSQL codebase in a way so it has APIs / extension points where your code has to diverge from core PostgreSQL? If these changes could be accepted by the upstream PostgreSQL project, then the amount of maintenance work you have to do would drop significantly. If you start working on upgrading to PostgreSQL 16 (the current development version) now and also do these refactorings and submissions to the upstream project, you could have it done and accepted by the time PostgreSQL 16 is released. Another option would be to keep up with upstream PostgreSQL on a commit-by-commit basis. This is not a very fun project (I was involved in such a project to port Google V8 commit-by-commit from ARM to MIPS - did it for 6 years), but the result is that you can follow the PostgreSQL feature set very closely. What do you think? |
I see upgrade to Postgres 13/15 is still on the github frontpage as being in progress, but is there any news regarding this? The lack of foreign key support on partitioned tables is currently holding our project back from migrating to yugabyte |
Hi @bmjhversteeg, This effort is actively underway. I will let the engineering team comment on the timeline if one is available at this time. We currently have two main workarounds for this issue - #15424 If you can reach out to me (@MarkoR (YB)) in our Community Slack I can share the function mentioned in #15422 if you would like to test with it. I have also created some documentation that can be shared that further clarifies your options for FKs on non-partitioned and partitioned tables. |
@mrajcevic01 Thanks a lot for your reply! I'll meet you on Slack. |
@bmjhversteeg I'm interested to know more about your use case needing foreign keys to partitioned tables. I think that in the context of YugabyteDB the need to reference a partitioned table from a non-partitioned one should be rare. I've detailed that in: https://dev.to/yugabyte/foreign-keys-referencing-partitioned-tables-in-yugabytedb-26pn but I'll be happy to see if I missed something. I'll ping you on slack |
This issue seems to have been open for a while now, and it's clear from the discussion thread that it's of substantial importance to many users. Could someone from the engineering team kindly provide an estimated timeline for the completion of the PostgreSQL 15 upgrade? I understand that it's a complex endeavor, and these things can be difficult to predict accurately, but a rough estimation would be helpful to understand when we might expect this upgrade. Thanks for all the hard work on this! |
Now, it seems to make sense to upgrade to version 17, not 15 |
@alexted which PG16 feature are you using? It is important to think in term of features to also remain compatible with previous versions of PostgreSQL |
As a longtime lurker on this 3.5 year old thread, with well-nigh zero (0) meaningful input from YB, that response seems rather tactless and impertinent. Shouldn't YB support a modern version of Postgres and let application writers and sysadmins worry about compatibility with older versions? |
I can go on and on with this list... |
@alexted YugabyteDB uses PostgreSQL only for the SQL layer so the features that are storage specific do not depend on the PostgreSQL compatibility. For example:
Just wanted to note that features on layers below the SQL API don't apply to YugabyteDB as-is. I agree that there are also great SQL features that we will benefit from. |
Thanks for your comment. besides the few things I mentioned that you mentioned, there is a lot more functionality from the current SQL layer of Postgres missing. Well, in this case, could you tell me if we should wait for the necessary functionality of the latest versions of PostgreSQL in YugabyteDB? |
@alexted Current state: Currently we are working on
Considering this is a very large effort, so currently do not have any fixed timeline yet. Though as we are getting closer to the completion of ongoing task, we will update the firm timeline for it. Please ping us for any additional question you may have. |
@sushantrmishra Look, April 8 is going to be a feature freeze in PostgreSQL. Perhaps, in that case, it makes sense for you to work with PostgreSQL version 17 at once? |
@alexted one of the reasons that this project is hard is because we're looking to support online-upgrade of the version, which isn't supported in normal PostgreSQL. Once we upgrade to PG15, and support online upgrade, it will be much easier to upgrade to newer versions of PostgreSQL. |
Jira Link: DB-1591
Motivation -
Phase 1 - Set up Postgres 15 branch for YSQL
pg15
YSQL branchpg15
branch./yb_build.sh --clang15 --sjb --rebuild-postgres --no-initdb
pg15
branchyugabyte-db/master
branchPhase 2 - Support YSQL database initialization (initdb)
template1
system tablessetup_auth
andsetup_depend
template0
,postgres
,yugabyte
, andsystem_platform
Phase 3 - Feature parity with current YSQL
Many features are already used internally as part of
initdb
(phase above)pg15
branchpg15
branchpg_stat_statements
,pg_hint_plan
,orafce
, etc.pg15
branch intomaster
Phase 4 - Enable select PostgreSQL v12 to v15 features
Phase 5 (future) - Enable all PostgreSQL v12 to v15 features
The text was updated successfully, but these errors were encountered: