[Proposal] Upgrade the PostgreSQL version from 14 to 16 #1095
Replies: 2 comments 3 replies
-
|
I have two questions from here:
Moreover, should one GitHub project or Google Sheet be created to help manage the upgrade progress for better transparency? Footnotes |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for initiating this important proposal. I fully support the goal of aligning Apache Cloudberry with upstream PostgreSQL enhancements. That said, there are several foundational areas that need clarification and community discussion to ensure the upgrade is successful, maintainable, and inclusive of all stakeholders. 🚩 Release Lifecycle Policy: UnclearThe proposal asserts:
However, the project has not yet published or discussed a formal release lifetime policy. This makes it difficult for users, downstream integrators, and commercial adopters to plan around version stability and upgrade timelines. Key open questions include:
📌 Recommendation: Here’s a suggested draft format to seed discussion: 📄 Example: Minimal Versioning and Support Policy## Apache Cloudberry Versioning and Support Policy (DRAFT)
Apache Cloudberry follows a major.minor.patch format:
- Major: Kernel upgrades or breaking changes (e.g., PG14 → PG16)
- Minor: Backward-compatible feature additions
- Patch: Bug and security fixes
| Version | PG Base | Status | Maintenance Target |
|---------|---------|----------|------------------------------|
| 2.0.x | PG14 | Active | Through at least 2027¹ |
| 3.0.x | PG16 | Planned | PG16 EOL + 1 year (tentative)|
¹ PG14 EOL is in 2026; Cloudberry 2.0 will continue receiving critical fixes beyond that date.
Upgrades will follow standard PostgreSQL tooling (e.g., `pg_upgrade`) where feasible. Changes to this policy will be proposed on the dev@ mailing list.🔄 Upgrade Path for Users: Not AddressedThere is no mention of how users are expected to upgrade from Apache Cloudberry 2.0 (PG14) to 3.0 (PG16). Key questions:
📌 Recommendation: Outline the expected upgrade path or link to a follow-up issue/mailing list thread where this will be clarified. 🌿 Development Workflow and Branching: Needs ClarificationAt the time of this proposal, Apache Cloudberry 2.0 has not yet been officially released. As such:
This raises an important question:
📌 Recommendation:
Keeping 🧪 Test Plan: Needs ClarificationWhile the proposal estimates ~3 months for regression fixes, it doesn’t specify:
📌 Recommendation: Expand the proposal to include:
🧩 Extension and Component Coordination: MissingApache Cloudberry includes many in-core components and bundled extensions (e.g., PXF, gpfdist, PL languages, workload manager). A PostgreSQL upgrade will almost certainly affect:
📌 Recommendation:
🌐 Downstream Ecosystem Impact: Private and Commercial ComponentsApache Cloudberry is widely used in derivative commercial and private deployments. Many such projects include non-public extensions or downstream forks. These groups depend on kernel compatibility and early visibility. 📌 Recommendation:
📊 Tracking and Transparency: SuggestedAs noted by @tuhaihe, the community would benefit from centralized tracking of the PG16 upgrade effort. 📌 Recommendation:
This improves visibility, onboarding, and roadmap clarity. ✅ Summary of Actionable Follow-ups
Thanks again for initiating this work. With these additional discussions and supporting plans in place, the PG16 upgrade can move forward in a way that benefits the entire Apache Cloudberry community — from committers to downstream integrators. Let me know if I can help turn any of these topics into individual GitHub issues or mailing list threads. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Proposers
No response
Proposal Status
Under Discussion
Abstract
We plan to upgrade the PostgreSQL version from 14 to 16 to leverage the latest features. Maintaining CloudberryDB's kernel version alignment ensures its dependent PostgreSQL components stay within the official maintenance cycle, thereby ensuring continuous access to bug fixes from the PostgreSQL community.
Motivation
The PostgreSQL community, home to the world's foremost database engineers, delivers substantial feature enhancements with each release. Sustaining version parity enables us to consistently benefit from PostgreSQL innovations, whose strategic value may parallel our own feature development efforts.
CloudberryDB's current kernel implementation (PostgreSQL 14) will reach end of life (EOL) next year, after which official security patches and bug fixes will no longer be available from PostgreSQL upstream.
PostgreSQL 15 contains many new features and enhancements, including:
Support for the SQL MERGE command.
Selective publication of tables' contents within logical replication publications, through the ability to specify column lists and row filter conditions.
More options for compression, including support for Zstandard (zstd) compression. This includes support for performing compression on the server side during pg_basebackup.
Support for structured server log output using the JSON format.
Performance improvements, particularly for in-memory and on-disk sorting.
PostgreSQL 16 contains many new features and enhancements, including:
Allow parallelization of FULL and internal right OUTER hash joins
Allow logical replication from standby servers
Allow logical replication subscribers to apply large transactions in parallel
Allow monitoring of I/O statistics using the new pg_stat_io view
Add SQL/JSON constructors and identity functions
Improve performance of vacuum freezing
Add support for regular expression matching of user and database names in pg_hba.conf, and user names in pg_ident.conf
Implementation
Based on historical upgrade patterns, we will execute a dual-phase upgrade process covering both versions 15 and 16. The technical workflow includes:
Merge new version:
git merge REL_16_STABLE && git add -u && git merge --continue
Conflict Resolution:
Manual resolution of merge conflicts from Phase 1
(Estimated: 1 month)
Cluster Initialization:
Bootstrap CloudberryDB clusters and debug fatal errors/panics
(Estimated: 0.5 months)
Test Suite Validation:
Remediate all regression test failures
(Estimated: 3 months)
This kernel modernization initiative is projected to complete within 4-5 months.
Rollout/Adoption Plan
No response
Are you willing to submit a PR?
Beta Was this translation helpful? Give feedback.
All reactions