Thank you very much.We should start a new topic to discuss how to update the kernel and maintain the various branches.
On Mon, Mar 2, 2026 at 11:01 PM Kirill Reshke <[email protected]> wrote: > On Tue, 3 Mar 2026, 08:38 Zhang Mingli, <[email protected]> wrote: > > > 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 > > > > > Ok > > > 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] > > > > > > On Tue, 3 Mar 2026, 08:38 Zhang Mingli, <[email protected]> wrote: > > > 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] > > > > > > On Tue, 3 Mar 2026, 08:38 Zhang Mingli, <[email protected]> wrote: > > > 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] > > > > >
