-
Notifications
You must be signed in to change notification settings - Fork 684
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
PG17 compatibility: Resolve compilation issues #7699
Conversation
a53a90f
to
65d055e
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## release-13.0 #7699 +/- ##
===============================================
Coverage ? 89.65%
===============================================
Files ? 274
Lines ? 59584
Branches ? 7436
===============================================
Hits ? 53418
Misses ? 4035
Partials ? 2131 |
65d055e
to
e71d521
Compare
I'm seeing a different issue compiling this branch on arm64/MacOS than I do on Against 17 (this branch):
Main against 16
|
if (es->memory) | ||
{ | ||
MemoryContextSwitchTo(saved_ctx); | ||
MemoryContextMemConsumed(planner_ctx, &mem_counters); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we switch back to older context after L454
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed the logic in the Postgres code here. Let me paste the relevant lines, where the context is not switched back. Do you think that is enough?
https://github.com/postgres/postgres/blob/REL_17_0/src/backend/commands/explain.c#L495-L512
https://github.com/postgres/postgres/blob/REL_17_0/src/backend/commands/prepare.c#L637-L642
Note to self; Only remaining commit to review is cfba6ff. update: done |
Btw, thank you for cleanly separating the work into commits, it made reviews so much easier! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. @rajeshkt78, would you like to review cfba6ff since it introduces some changes to cdc subsystem, or should we just merge this?
Looks like PG 17 introduced a new ACL called PG commit: Our deparser does not handle that
I understand that this commit is for getting Citus compile against PG17. Let's create an issue to track "ACL_MAINTAIN" should be supported. |
MergeAction can have 3 merge kinds (now enum) in PG17, write compat New merge kinds should be handled in deparser and Merge logic in Citus. Let's track this as a github issue. |
) | ||
|
||
#endif | ||
static inline CitusNode * |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we delete two lines here:
/* support for CitusNewNode() macro */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still have CitusNewNode(size_t size, CitusNodeTag tag)
function, so I guess not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CitusNode *newCitusNodeMacroHolder;
is not referenced anywhere. So I assumed it was related to getting around an issue with macro usage. Now since we have a function instead, this line may be redundant and confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noticed that, you are right. It is redundant. Let me remove it.
This is prep work for successful compilation with PG17 PG17added foreach_ptr, foreach_int and foreach_oid macros Relevant PG commit 14dd0f27d7cd56ffae9ecdbe324965073d01a9ff postgres/postgres@14dd0f2 We already have these macros, but they are different with the PG17 ones because our macros take a DECLARED variable, whereas the PG16 macros declare a locally-scoped loop variable themselves. Hence I am renaming our macros to foreach_declared_ I am separating this into its own PR since it touches many files. The main compilation PR is #7699
Relevant PG commit d060e921ea5aa47b6265174c32e1128cebdbc3df postgres/postgres@d060e92
Relevant PG commit 041b96802efa33d2bc9456f2ad946976b92b5ae1 postgres/postgres@041b968
Relevant PG commit: 89e5ef7e21812916c9cf9fcf56e45f0f74034656 postgres/postgres@89e5ef7
Relevant PG commit: 08e6344fd6423210b339e92c069bb979ba4e7cd6 postgres/postgres@08e6344
Relevant PG commit: f696c0cd5f299f1b51e214efc55a22a782cc175d postgres/postgres@f696c0c
Relevant PG commit: de3600452b61d1bc3967e9e37e86db8956c8f577 postgres/postgres@de36004
Relevant PG commit: 50c67c2019ab9ade8aa8768bfe604cd802fe8591 postgres/postgres@50c67c2
Relevant PG commit: 509199587df73f06eda898ae13284292f4ae573a postgres/postgres@5091995
Relevant PG commit: 75680c3d805e2323cd437ac567f0677fdfc7b680 postgres/postgres@75680c3
Relevant PG commit: 0294df2f1f842dfb0eed79007b21016f486a3c6c postgres/postgres@0294df2
Relevant PG commit: 5de890e3610d5a12cdaea36413d967cf5c544e20 postgres/postgres@5de890e
…ON_COUNT Relevant PG commit: a6be0600ac3b71dda8277ab0fcbe59ee101ac1ce postgres/postgres@a6be060
Relevant PG commit: 9e9931d2bf40e2fea447d779c2e133c2c1256ef3 postgres/postgres@9e9931d
Relevant PG commits: 28f3915b73f75bd1b50ba070f56b34241fe53fd1 postgres/postgres@28f3915 ab355e3a88de745607f6dd4c21f0119b5c68f2ad postgres/postgres@ab355e3 024c521117579a6d356050ad3d78fdc95e44eefa postgres/postgres@024c521
postgres refactored newNode() in PG 17, the main point for doing this is the original tricks is no longer neccessary for modern compilers[1]. This does the same for Citus. This should have no backward compatibility issues since it just replaces palloc0fast with palloc0. This is good for forward compatibility since palloc0fast no longer exists in PG 17. [1] https://www.postgresql.org/message-id/[email protected] (cherry picked from commit 4b295cc)
@emelsimsek you are right, it's not part of the compile PR. We might need a separate issue for new features in PG17 which will encapsulate these subtasks, like this one: #7138. For now, I added your comments in here #7708 |
e71d521
to
cd76567
Compare
PG17 compatibility - Part 2 #7699 was the first PG17 compatibility PR merged to main branch, which provided ONLY successful Citus compilation with PG17.0. This PR, consider it as Part 2, provides ruleutils changes for PG17. Ruleutils changes is the first thing we should merge, after successful build. It's the core for deparsing logic in Citus. # Question: How do we add ruleutils changes? - We add a new ruleutils file specific to PG17. - We keep track of the changes in Postgres's ruleutils file from here https://github.com/postgres/postgres/commits/REL_17_0/src/backend/utils/adt/ruleutils.c - Per each commit in that history that belongs only to 17.0, we add the relevant changes to static functions to our ruleutils file for PG17. It's like a manual commit copying. # Check the PR's commits for detailed steps https://github.com/citusdata/citus/pull/7725/commits
This is the final commit that adds PG17 compatibility with Citus's current capabilities. You can use Citus community, release-13.0 branch, with PG17.1. --------- Specifically, this commit: - Enables PG17 in the configure script. - Adds PG17 tests to CI using test images that have 17.1 - Fixes an upgrade test: see below for details In `citus_prepare_upgrade()`, don't drop any_value when upgrading from PG16+, because PG16+ has its own any_value function. Attempting to do so results in the error seen in [pg16-pg17 upgrade](https://github.com/citusdata/citus/actions/runs/11768444117/job/32778340003?pr=7661): ``` ERROR: cannot drop function any_value(anyelement) because it is required by the database system CONTEXT: SQL statement "DROP AGGREGATE IF EXISTS pg_catalog.any_value(anyelement)" ``` When 16 becomes the minimum supported Postgres version, the drop statements can be removed. --------- Several PG17 Compatibility commits have been merged before this final one. All these subtasks are done #7653 See the list below: Compilation PR: #7699 Ruleutils PR: #7725 Sister PR for tests: citusdata/the-process#159 Helpful smaller PRs: - #7714 - #7726 - #7731 - #7732 - #7733 - #7738 - #7745 - #7747 - #7748 - #7749 - #7752 - #7755 - #7757 - #7759 - #7760 - #7761 - #7762 - #7765 - #7766 - #7768 - #7769 - #7771 - #7774 - #7776 - #7780 - #7781 - #7785 - #7788 - #7793 - #7796 --------- Co-authored-by: Colm <[email protected]>
PG17 compatibility - Part 1
This PR, together with #7700, provides successful compilation against PG17.0.
Notes to reviewer:
release-13.0
branch later, when the PG17 support is fully added.(Original PR against the main branch #7651)