Hi all, Frankly, I'm a bit surprised this is even being debated. In all my years working on database kernel development (Greenplum/GPDB), we never once considered merging minor upstream releases into the main development branch. This was a well-understood discipline — and for good reason.
The main branch should always be moving toward the next major kernel target (PG16), not absorbing lateral patches from the current stable line. PG 14.4 → 14.20 commits are version-specific backports — they belong in REL_2_STABLE, which is the branch that actually ships PG14 to users. Merging ~1352 PG14-specific commits into main is asking for trouble. Every single one becomes a potential merge conflict when we cherry-pick Cloudberry features into the PG16 branch. And all these fixes already exist in PG16 in their proper form — so this work would be entirely redundant once the kernel upgrade lands. +1 to Jinbao's position: PG 14.4 → 14.20 → REL_2_STABLE directly CVE-only fixes → main (already mostly done) Keep main clean for PG16 upgrade This is how Greenplum always handled it, and it's how PostgreSQL itself manages its branches — fixes flow from master to stable, not the other way around. Let's not create unnecessary pain for the people doing the kernel upgrade. On 2026/03/03 02:30:37 Jinbao Chen 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] > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
