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] > >
