Hi Kirill, I think only cherry-pick CVE fixes is fine.
But I would suggest it's better to wait until REL_3_STABLE is created before we bring in any code, even CVE fixes. In order to streamline the postgres code upgrade process , I suggest that the cloudberry main branch should exclusively merge from the postgres master branch. Any additional code from postgres stable branches should be merged into the corresponding cloudberry stable branches. Consider a scenario: our current Postgres core version is 14.14, and we are trying to merge up to 16.9. Generally, we want any changes in Postgres 16 to automatically override the Postgres 14 code without causing conflicts. However, since the release date of 14.14 might actually be later than 16.9, it could lead to unexpected conflicts or incorrect automatic merges. If we maintain a strictly linear progression for the Postgres core code, conflicts will only occur in places where both Cloudberry and Postgres have modified the same lines. On Fri, May 29, 2026 at 2:29 PM 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
