If we've already decided to upgrade from pg14 to pg16, what's the point of introducing code from pg14.4 to pg14.20 onto the master branch? The future Cloudberry 3x will be released based on pg16, so the code from pg14.4 to pg14.20 can only be applied to the Cloudberry 2x. In that case, why not put this code on the REL_2_STABLE branch?
On Mon, Feb 9, 2026 at 5:07 PM Kirill Reshke <[email protected]> wrote: > On Mon, 9 Feb 2026 at 13:37, Jinbao Chen <[email protected]> wrote: > > > > I believe the introduction of Postgres stable branch code should occur on > > Cloudberry's stable branches, > > such as REL_2_STABLE. > > > > In theory, our main branch should only upgrade the code of the PostgreSQL > > master branch. > > yes, agreed, cloudberry main == cloudberry over pg19 would be great. > > > Only after we switch to a > > stable branch such as 'REL_2_STABLE' should we upgrade the code of the > > PostgreSQL stable branch. > > Introducing a large amount of code from the Postgres stable branch into > > cloudberry/main will cause significant > > problems for main version upgrades. The introduction of non-linear codes > > can cause intractable conflicts. > > > > I suggest this upgrade should be performed on REL_2_STABLE. > > I see your rationale on this, and agree with it. But things are > already very complicated for the main branch... > I think we should cherry-pick all CVE fixes here for sure, and given > that main is over PG14, this would be a cherry-pick from > REL_14_STABLE. > However, I can see that if this rebase process is fully completed > against main (adding ~1300 commits to it), it would be extremely > troublesome to complete 14-16 kernel upgrade. > > So, my (updated) proposal: > > 1) Do kernel (14.4 - 14.20) rebase over REL_2_STABLE > 2) Have all CVE fixes from 14.4 - 14.20 into main (almost done, actually) > 3) Do 16.9 - 16.12 upgrade in cbdb-postgres-merge/ branch (I can also > help with that) > > 3*) In some distant future, the main branch of cloudberry will always > be in sync with Postrges master... > > Does it sound? > > > > > On Fri, Feb 6, 2026 at 6:20 PM Dianjin Wang <[email protected]> > wrote: > > > > > Cool! I created a GitHub Project: > > > https://github.com/orgs/apache/projects/572/views/1, feel free to > > > edit. > > > > > > Also agreed with your schema. Thanks! > > > > > > Best, > > > Dianjin Wang > > > > > > On Fri, Feb 6, 2026 at 4:34 PM Kirill Reshke <[email protected]> > > > wrote: > > > > > > > > Here [0] is an old-style excel with all commits between 14.4 and > > > > 14.20, just a list without any sort of analysis for now. > > > > > > > > I guess we can create github project for this upgrade process, and > > > > have here tickets for each incremental step (14.4 - 14.5, 14.5 - > 14.6) > > > > > > > > So, we will use both [0] and github projects. > > > > > > > > Also, regarding the 2.x/3.x policy. I propose a scheme where > > > > cherry-pick PR (which in turn can be a number of closely-related > > > > commits) is always created for the main branch, reviewed and merged > > > > here, and then Cloudberry committer, responsible for the PR simply > > > > pushes changes to REL_2_x without addiniginal PR/review. Does it > > > > sound? I think 14.4 - 14.20 commits are good in terms of code > quality > > > > and ABI stability, so this might work. > > > > > > > > > > > > Thoughts? > > > > > > > > [0] > > > > https://docs.google.com/spreadsheets/d/1vjjEb39QPyXO-nDJZ0tHAtReIQKka0S2YnD2r1AFhkk/edit?gid=0#gid=0 > > > > > > > > On Fri, 6 Feb 2026 at 12:22, Kirill Reshke <[email protected]> > > > wrote: > > > > > > > > > > On Fri, 6 Feb 2026 at 09:13, Dianjin Wang <[email protected]> > > > wrote: > > > > > > > > > > > > Hi Kirill, > > > > > > > > > > > > On Thu, Feb 5, 2026 at 11:08 PM Kirill Reshke < > > > [email protected]> wrote: > > > > > > > > > > > > > > Sure > > > > > > > This will in fact resolve many problems, not only CVE > > > > > > > So, how do we organize this? Do we need big excel as in gpdb > > > > > > > cherry-pick process? > > > > > > > > > > > > > > > > > > > I think both approaches could work well — a shared Google Sheet > or a > > > > > > GitHub Project/issue tracker. The key is to keep the progress > > > > > > transparent and make it easy for others to participate and > > > contribute. > > > > > > > > > > > > I want to share more ideas on the minior kernel upgrade for the > > > reference. > > > > > > > > > > > > Between PG 14.4 and 14.20 there are ~1352 commits, so a phased > > > upgrade > > > > > > could be a reasonable approach. For example, upgrading > incrementally > > > > > > (14.4 → 14.5 → 14.6, etc. ~100 commits per step) or grouping > several > > > > > > minor versions per step could help keep the process more > controlled > > > > > > and reduce risk. Curious to hear what others think. > > > > > > > > > > I don't have a strong opinion here. But to keep the Cloudberry > project > > > > > more Postgres-y, let's try an incremental approach . > > > > > > > > > > > BTW, would you be interested in leading this upgrade effort, if > you > > > > > > have the bandwidth? Having a coordinator would greatly help drive > > > this > > > > > > forward. > > > > > > > > > > I would love to! But I'm a little inexperienced in the GitHub > > > > > Project/issue tracker. Anyway I can cherry-pick for sure and manage > > > > > commit statuses/reviewing other people's PRs. > > > > > > > > > > > Best, > > > > > > Dianjin Wang > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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] > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > >
