With [0], [1] and [2] we will have all CVE fixes back-patched into main [0] https://github.com/apache/cloudberry/pull/1794 [1] https://github.com/apache/cloudberry/pull/1793 [2] https://github.com/apache/cloudberry/pull/1811
Will move forward into creating a 16.9 - 16.14 migration project? On Fri, 29 May 2026 at 23:29, Kirill Reshke <[email protected]> wrote: > > Sure, let's create a 16.9 -> 16.14 + migration project. > Also, I think it's important to backport all CVE fixes from 16.10, > 16.11, 16.12, 16.13 & 16.14 urgently (like here[0]), and then > backport all other patches in a lazy way. > > Maybe "urgently" is not very correct term for this, but I think safety > first here, to ensure we never miss something important once cbdb over > pg16 will be released > > > [0] https://github.com/apache/cloudberry/pull/1773 > > On Fri, 29 May 2026 at 18:47, Dianjin Wang <[email protected]> wrote: > > > > Hi all, > > > > One additional thought regarding the longer-term maintenance strategy > > after the PG16 merge stabilization work. > > > > Since the current upgrade work brings Apache Cloudberry to PostgreSQL > > 16.9, I wonder whether, after the FIXME items and stabilization work > > are largely completed, we should consider continuing to roll forward > > within the PostgreSQL 16.x series (for example toward newer upstream > > minor releases such as 16.14 or later), before eventually starting a > > future PG18 upgrade cycle. > > > > Over the past year, while the PG14 → PG16 merge work was ongoing, > > PostgreSQL upstream has continued releasing additional 16.x minor > > updates containing bug fixes, stability improvements, and > > security-related fixes. > > > > I think continuing to track newer PostgreSQL 16.x minor releases > > incrementally may provide several benefits: > > * Reduce long-term divergence from PostgreSQL upstream. > > * Avoid accumulating another large maintenance gap. > > * Make future major-version upgrades easier and more incremental. > > * Help establish a more continuous upstream synchronization model for > > Cloudberry, rather than large periodic jumps. I think a rolling-update > > style upstream synchronization approach may help the project evolve > > more incrementally over time. > > > > Of course, I think stabilization and FIXME resolution should remain > > the first priority after the current merge lands. But once things > > become more stable, this may be a worthwhile direction for the > > community to consider. > > > > Just sharing this as a future maintenance thought for discussion. > > > > Best, > > Dianjin Wang > > > > On Tue, May 26, 2026 at 10:16 PM Kirill Reshke <[email protected]> > > wrote: > > > > > > Okay, so if I'm reading this correctly it's fine if I merge > > > https://github.com/apache/cloudberry/pull/1736 today, so we will be having > > > all viral fixes is current main. > > > I can also take an effort of merging this into to-be-main (pg16 merge) > > > branch, as well as other 16.10-16.14 CVE fixes. > > > Note that I'm speaking only about security fixes, which is about 50 > > > commits, not whole 16.10-16.14 range > > > > > > On Tue, 26 May 2026, 08:44 Dianjin Wang, <[email protected]> wrote: > > > > > > > Hi all, > > > > > > > > Thanks everyone for the discussion. > > > > > > > > At this point, it seems the general consensus is leaning toward moving > > > > forward with merging the PG16 upgrade into the main branch soon. I > > > > respect and support the community consensus process here - disagree > > > > and commit, so let’s move forward together. > > > > > > > > That said, before the final merge operation happens, I still think it > > > > would be beneficial to leave a little more time (perhaps 1~2 more > > > > days) so contributors from other time zones also have a fair > > > > opportunity to participate in the discussion and review process. > > > > > > > > Also, in the parallel 2.2 release discussion thread started by Leonid, > > > > there was a suggestion to land key 2.2 features into the 2.x branch > > > > first. I personally support this direction. I think it addresses many > > > > of the concerns I mentioned earlier around transition coordination and > > > > ongoing in-flight work. > > > > > > > > With the 2.2 release work continuing for more time, I now agree that > > > > moving the PG16 kernel upgrade into the main branch sooner probably > > > > makes more sense overall. > > > > > > > > Before the merge happens, I think there are still several preparation > > > > steps that would help make the transition smoother (I’m happy to help > > > > with these tasks): > > > > > > > > * Create a copy branch from the current main branch (for example > > > > `PG14_ARCHIVE`) to mirror the existing PG14-based code line. > > > > * Apply a similar strategy to related ecosystem repositories where > > > > appropriate, including PXF and cloudberry-backup. > > > > * Clearly document the transition strategy for contributors, including > > > > which branches should receive PG14 fixes versus PG16-targeted > > > > development (can do after the PG16 merging). > > > > > > > > I think these steps can help reduce disruption during the transition > > > > period while still allowing us to move the PG16 work forward. > > > > > > > > Thanks again to everyone driving this huge effort. > > > > > > > > > > > > Best, > > > > Dianjin Wang > > > > > > > > On Tue, May 26, 2026 at 11:05 AM Jinbao Chen <[email protected]> > > > > wrote: > > > > > > > > > > When a new PR is merged into the main branch, the feature branch > > > > > should, > > > > in > > > > > theory, > > > > > rebase onto the main branch. However, because this specific merge PR > > > > > is > > > > > massive—containing > > > > > all the code for Postgres 15 and 16 along with numerous bug fixes—a > > > > rebase > > > > > has become > > > > > practically impossible. Consequently, the merge PR must instead merge > > > > > the > > > > > main branch into > > > > > itself, which will create an additional merge commit on top of the > > > > Postgres > > > > > 16 merge. Eliminating > > > > > this redundant merge commit requires highly complex Git operations, > > > > > which > > > > > takes time and introduces risk. > > > > > > > > > > Other PRs do not suffer from this issue. They can follow the standard > > > > > workflow and rebase normally, > > > > > which is much simpler and less risky than handling the merge PR. > > > > > > > > > > At the same time, if we choose to wait two to three weeks for existing > > > > PRs > > > > > to merge, new > > > > > PRs will inevitably keep coming in anyway. What, then, would be the > > > > > point > > > > > of waiting? > > > > > > > > > > On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <[email protected]> > > > > wrote: > > > > > > > > > > > Hi Jinbao, all, > > > > > > > > > > > > First of all, I completely understand the concern about keeping the > > > > main > > > > > > branch blocked for too long, especially considering the size of this > > > > work > > > > > > and the complexity of continuously rebasing such a large upgrade > > > > branch. (I > > > > > > believe some PRs an be merged by now, but still not somehow). > > > > > > > > > > > > However, I think this transition is not only about merging the > > > > PostgreSQL > > > > > > 16 kernel into the main repository itself, but also about preparing > > > > > > the > > > > > > broader Cloudberry ecosystem for the transition from PG14 to PG16. > > > > > > > > > > > > For example, several ecosystem components and CI pipelines are > > > > currently > > > > > > still tightly coupled with the existing main branch, including: PXF, > > > > > > cloudberry-backup and potentially other downstream components. > > > > > > > > > > > > Some time may be needed for contributors to evaluate how we can > > > > > > support > > > > > > both PG14 and PG16 during the transition period. > > > > > > > > > > > > Also, the past three days included the weekend, and according to > > > > > > normal > > > > > > Apache community practice, review windows around weekends are > > > > > > usually > > > > > > considered differently since many contributors may be offline or on > > > > > > vacation. > > > > > > > > > > > > Another concern is that we are also about to begin discussions > > > > > > around > > > > the > > > > > > 2.2 release (Leonid will send a discussion email later maybe), while > > > > at the > > > > > > same time there are still many active PRs currently under review on > > > > top of > > > > > > the PG14-based main branch — especially around Orca, PAX, Planner, > > > > > > and > > > > > > related areas. My concern is that once the main branch fully > > > > > > switches > > > > to > > > > > > the PG16 kernel, many of these existing PRs may will not be simply > > > > > > cherry-picked from the main to the 2.x release. I think it indeed > > > > needs a > > > > > > good balance to handle with this situation. Everyone handles the > > > > rebased > > > > > > work for PG16, or we do the rebase only once in the PG16 PR. > > > > > > > > > > > > Yesterday I had a brief private discussion with Max, my opinions (no > > > > > > decision, just sharing): > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > > allowing a transition/review window (for example around 2–3 > > > > > > weeks), > > > > > > - > > > > > > > > > > > > accelerating review and merge of the currently active PG14-based > > > > > > PRs > > > > > > during this period, > > > > > > - > > > > > > > > > > > > and then temporarily locking the main branch and performing a > > > > > > final > > > > > > rebase/synchronization of the PG16 branch once - You don’t need > > > > > > to > > > > > > repeatly > > > > > > rebase to catch up the main’s changes > > > > > > > > > > > > I think this could help: > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > > reduce repeated rebase work for the PG16 PR, > > > > > > - > > > > > > > > > > > > give ecosystem components some reaction/adaptation time, help us > > > > > > coordinate with our next 2.x minor release, > > > > > > - > > > > > > > > > > > > and help existing contributors land their in-flight work before > > > > > > the > > > > > > kernel transition fully happens. > > > > > > > > > > > > A good strategy will help us. Just sharing these thoughts for > > > > discussion. > > > > > > We can continue the discussion here, or an open meeting on this. > > > > > > Thanks > > > > > > again for driving this huge effort forward. > > > > > > > > > > > > Best, > > > > > > Dianjin Wang > > > > > > > > > > > > Jinbao Chen <[email protected]>于2026年5月26日 周二01:27写道： > > > > > > > > > > > > > Hi all, > > > > > > > It has been three days since the PR was submitted. I intend to > > > > > > > merge > > > > it > > > > > > > into the main branch today. > > > > > > > Why I chose not to wait any longer: > > > > > > > Firstly, we cannot allow the main trunk to be blocked for an > > > > > > > extended > > > > > > > period. > > > > > > > Secondly, the sheer size of this PR makes a thorough and effective > > > > review > > > > > > > impossible. > > > > > > > > > > > > > > After merging, we will start fixing the FIXMEs. I am currently > > > > sorting > > > > > > them > > > > > > > out and converting them > > > > > > > into features in project > > > > > > > https://github.com/orgs/apache/projects/497 > > > > > > > > > > > > > > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke < > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > On Mon, 25 May 2026 at 08:44, Zhang Mingli > > > > > > > > <[email protected]> > > > > > > wrote: > > > > > > > > >I think we should go ahead and merge it in. > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > > > > > Kirill Reshke > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- > Best regards, > Kirill Reshke -- Best regards, Kirill Reshke --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
