I do not support upgrading to 14.20. Upgrading directly to 16.9 is already
underway. Upgrading to 14.20 would increase the complexity of 16.9, and it's
just an intermediate state. Instead of spending time upgrading to 14.20, it's
better to cooperate and upgrade directly to 16.9.
> From: "Jinbao Chen"<[email protected]>
> Date: Tue, Mar 3, 2026, 10:45
> Subject: Re: [D] [Ideas] Upgrade PostgreSQL 14 base from 14.4 to 14.20 for
> Cloudberry main branch [cloudberry]
> To: <[email protected]>
> > We should not freeze the PG version that main is based on. If main
> > cannot continuously track upstream improvements, we lose one of the
> > key advantages of being a PostgreSQL downstream project. In other
> > words, `main` should remain the `upstream` for `REL_x_STABLE`, not the
> > other way around.
>
> We do not freeze the main branch. Cloudberry features still need to enter
> the
> main branch first, and then cherry-pick to the 2.x branch.
>
> `main` should remain the `upstream` main. REL_x_STABLE should remain the
> `upstream` for `REL_x_STABLE`
>
> On Mon, Mar 2, 2026 at 9:37 PM Jinbao Chen <[email protected]> wrote:
>
> > If Cloudberry 3.x requires the latest fixes from pg14.20, we only need to
> > upgrade the latest
> > REL_16_STABLE code after upgrading the kernel from pg14 to pg16. If
> > Cloudberry 2.x requires
> > the latest fixes, then I think it's sufficient to place these fixes in
> > REL_2_STABLE. Besides
> > increasing the complexity, what other purpose does merging pg14.20 into
> > the main branch
> > and then cherry-picking it into REL_2_STABLE serve?
> >
> > On Mon, Mar 2, 2026 at 9:30 PM Jinbao Chen <[email protected]>
> > wrote:
> >
> >> The discussion above still seems to suggest that version 14.20 should be
> >> merged into the main branch, which I completely don't understand.
> >>
> >> On Tue, Feb 10, 2026 at 8:03 AM Leonid Borchuk <[email protected]>
> >> wrote:
> >>
> >>> +1 for
> >>> + absorbing PostgreSQL 14.4 → 14.20 (and future PG14 updates) into the
> >>> current `main` branch
> >>> + do not freeze main branch
> >>>
> >>> We could decide how to simplify rebasing PG16 work later. Most likely, it
> >>> will be enough to figure out how to exclude absorbing from PG14 commits.
> >>>
> >>> On Tue, Feb 10, 2026 at 3:14 PM Kirill Reshke <[email protected]>
> >>> wrote:
> >>>
> >>> > On Tue, 10 Feb 2026 at 15:47, Dianjin Wang <[email protected]>
> >>> wrote:
> >>> > >
> >>> > > I think we need to make a final decision on this; otherwise our work
> >>> > > will be blocked.
> >>> > >
> >>> > > My +1 vote is to absorb PostgreSQL 14.4 → 14.20 (and future PG14
> >>> > > updates) into the current `main` branch first, and then cherry-pick
> >>> > > the changes from `main` into `REL_2_STABLE`.
> >>> >
> >>> > I guess the only major issue here is how pg14-16 rebase would deal
> >>> > with that. After 16 pg kernel upgrade work, we should cherry-pick all
> >>> > commits from main to cbdb-postgres-merge branch. Well, I guess we can
> >>> > just not do that for 14.4-14.20 commits... Looking for Jinbao Chen
> >>> > comment here
> >>> >
> >>> >
> >>> > > We should not freeze the PG version that main is based on. If main
> >>> > > cannot continuously track upstream improvements, we lose one of the
> >>> > > key advantages of being a PostgreSQL downstream project. In other
> >>> > > words, `main` should remain the `upstream` for `REL_x_STABLE`, not
> >>> the
> >>> > > other way around.
> >>> >
> >>> > +1 on that
> >>> >
> >>> > > Looking forward to more voices.
> >>> > >
> >>> > > Best,
> >>> > > Dianjin Wang
> >>> >
> >>> >
> >>> > --
> >>> > Best regards,
> >>> > Kirill Reshke
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: [email protected]
> >>> > For additional commands, e-mail: [email protected]
> >>> >
> >>> >
> >>>
> >>
>
