The pull request of merge postgres 15 and 16 is created

[Jinbao Chen <ch...@gmail.com>]

Hi all,

I am very glad that we have finally completed the merge of Postgres 15 and
16, and everyone is more

than welcome to review it.Here are some of the new features:

Key features and changes, sorted by importance:

   1.

   MERGE command
   -

      SQL-standard MERGE for INSERT/UPDATE/DELETE in a single statement.
      -

      ruleutils decompilation, PlaceHolderVar support in actions
      -

      Fixes for partitioned tables, cross-partition triggers, RLS,
      -

      EvalPlanQual, self-modified tuples, pg_stat_statements
      2.

   Logical replication enhancements
   -

      Built-in support for prepared transactions (2PC)
      -

      Enable two-phase via replication protocol
      -

      Streaming changes after speculative aborts
      -

      New pg_create_subscription predefined role
      -

      Parallel apply workers (PG 16)
      -

      Row/column filtering, schema-level publication (PG 15)
      -

      Critical fix for data loss in logical replication
      -

      Slot invalidation, snapshot, and memory leak fixes
      3.

   SQL/JSON
   -

      IS JSON predicate
      -

      Standard JSON constructor functions (json_array, json_object,
      json_scalar, json_serialize)
      -

      Auto-generated query jumbling via gen_node_support.pl
      -

      Fix json_array() subquery double transformation
      4.

   WAL and storage subsystem
   -

      LZ4 compression for full-page writes (FPW)
      -

      Custom WAL resource managers
      -

      Skip WAL recycling/preallocation during archive recovery
      -

      XLOG_FPI_FOR_HINT honors full_page_writes setting
      -

      Direct I/O support on macOS
      -

      Buffer manager infrastructure refactor for faster relation extension
      -

      New smgrzeroextend(), FileZero(), FileFallocate()
      -

      Remove HeapBitmapScan skip_fetch optimization (correctness issue)
      -

      WAL/Recovery separation: xlogrecovery.c, xlogprefetcher.c (PG 15)
      -

      Backup sink architecture (PG 15)
      5.

   Query optimizer / executor
   Performance:
   -

      Hash table acceleration for NOT IN(values)
      -

      Datum sorts for single-column sorts
      -

      Result Cache renamed to Memoize with ongoing fixes
      -

      Parallel Hash Full Join
      -

      Reduced planning cost for deeply-nested views
      -

      Fewer pallocs when building partition bounds
      -

      Outer join optimization enhancement (PG 16)
      -

      Symmetric hash join optimization (PG 16)
      Critical fixes:
      -

      Planner failure to identify multiple hashable ScalarArrayOpExprs
      -

      Consistent whole-row Var construction in parsing and planning
      -

      WindowAgg evaluation crash
      -

      WITH RECURSIVE UNION assert failure
      -

      ORDER BY / DISTINCT aggregates with FILTER
      -

      setrefs.c missing expression processing on prune steps
      -

      Parallel Hash Join extreme skew detection
      6.

   pgstat monitoring enhancements
   pgstat shared memory rewrite (PG 15):
   -

      Stats collector process removed; stats now in shared memory
      -

      Monolithic pgstat.c split into 14 files under utils/activity/
      pg_stat_io (PG 16 new view):
      -

      Detailed I/O statistics: shared buffer hits, I/O times, writeback
      pg_stat_statements:
      -

      JIT counters, temp file block I/O timing
      -

      Utility query string normalization, MERGE support
      -

      32-bit integer overflow fix
      Other:
      -

      pg_stat_wal time accumulation as instr_time
      -

      Macro-generated pg_stat_get*() functions for tables and databases
      -

      Enhanced pg_stat_reset_single_table_counters
      -

      SP-GiST index scans counted in pg_stat
      -

      New test helpers: pg_stat_force_next_flush(), pg_stat_have_stats()
      7.

   libpq and client protocol
   -

      New PQsendFlushRequest
      -

      Pipeline mode state machine fix
      -

      SASL code refactored to generic interface
      -

      Escape function fixes for invalid encoding data (security)
      -

      PQescapeLiteral()/PQescapeIdentifier() length handling fix
      -

      New pg_encoding_set_invalid()
      -

      Build-time check that libpq doesn't call exit()/abort()
      8.

   Security and privilege model
   -

      CREATEROLE privilege restrictions (major security improvement)
      -

      New GUCs: createrole_self_grant, reserved_connections
      -

      New predefined roles: pg_maintain, pg_create_subscription
      -

      Non-superuser predefined roles for vacuum/analyze
      -

      Revoke PUBLIC CREATE from public schema (now owned by
      pg_database_owner)
      -

      Security invoker views (SECURITY INVOKER)
      -

      session_authorization and role interaction fixes
      -

      scram_SaltedPassword() integer overflow fix
      9.

   pg_dump / pg_upgrade / pg_basebackup toolchain
   pg_dump:
   -

      Generic compression API, zstd support, LZ4 frame-only format
      pg_basebackup:
      -

      Extended compression options, server-side compression with -Fp
      -

      Client-side LZ4 decompression, parallel zstd compression
      pg_upgrade:
      -

      Fix unintentional 'NULL' string literal
      -

      Fix XMLSERIALIZE(NO INDENT) cross-version upgrade
      -

      pg_dumpall handling of dangling OIDs in pg_auth_members
      10.

   Partitioned table improvements
   -

      Self-referencing FKs in partitioned tables
      -

      Detach partition with top-level FK fix
      -

      Reset relhassubclass on ATTACH
      -

      Trigger rename consistency, preserve firing state on clone
      -

      Disallow partitionwise join/grouping on collation mismatch
      11.

   ICU and collation
   -

      Build ICU support by default
      -

      initdb uses uloc_getDefault()
      -

      CREATE DATABASE LOCALE applies to all collation providers
      12.

   Node support function auto-generation (FIXME)
   -

      gen_node_support.pl auto-generates
      copyfuncs/equalfuncs/outfuncs/readfuncs
      -

      Query jumbling code auto-generation
      -

      NodeTag ABI stability check
      13.

   Global renames and structural changes
   -

      RelFileNode -> RelFileLocator (pervasive rename across hundreds of
      files)
      -

      GUC system split: guc.c -> guc.c + guc_tables.c + guc_funcs.c
      -

      varatt.h separated from postgres.h
      -

      Test framework: PostgresNode.pm -> PostgreSQL::Test::Cluster
      14.

   SQL types and functions
   -

      Numeric scale allows negative or greater than precision
      -

      New ANY_VALUE aggregate function
      -

      unnest(multirange), range_agg with multirange inputs
      -

      pg_size_pretty/pg_size_bytes support petabytes
      -

      ALTER TABLE SET ACCESS METHOD
      -

      SYSTEM_USER function
      -

      numeric_mul() overflow fix
      15.

   psql improvements
   -

      PSQL_WATCH_PAGER for \watch command
      -

      New \drg command for role grants
      -

      \copy from sends data in larger chunks
      -

      pg_waldump --rmgr multiple specification
      16.

   Critical data corruption and crash fixes
   -

      Fix data corruption when relation truncation fails
      -

      Fail instead of corrupting page header on non-LP_NORMAL TID update
      -

      Fix unsafe BufferDescriptors access
      -

      GB18030 SIGSEGV from out-of-bounds read
      -

      Snowball stemmer null pointer dereference after OOM
      -

      Rare standby assertion failure on primary restart
      -

      catcache invalidation during list entry construction
      17.

   Vacuum / Autovacuum
   -

      Parallel VACUUM (PG 16, vacuumparallel.c new file)
      -

      ON COMMIT DELETE ROWS avoids ERROR after relhassubclass=f
      -

      Use WaitLatch() instead of pg_usleep() at end-of-vacuum truncation
      -

      Prevent numeric overflow in parallel numeric aggregates
      -

      ANALYZE preserves relhasindex for partitioned tables


Currently, there are still some features that are not fully functional yet.
We have left some "FIXME" tags,

which will be fixed one after another in the coming weeks. We will create a
feature for each "FIXME" in

the project board, and anyone is welcome to help fix them:
https://github.com/orgs/apache/projects/497


Since the amount of code in this merge is massive, handling conflicts will
be very troublesome if new code

is merged into the main branch. Therefore, please temporarily pause merging
any code for the next few days.


Below is the list of contributors to this merge.

Jinbao Chen <ch...@gmail.com>

liushengsong <ls...@gmail.com>

reshke <re...@double.cloud>

Hao Wu <gf...@gmail.com>

Jianghua.yjh <yj...@gmail.com>

Dianjin Wang <wa...@gmail.com>

Re: The pull request of merge postgres 15 and 16 is created

[Dianjin Wang <wa...@gmail.com>]

Hi all,

Congratulations on reaching this milestone — this is a huge amount of
work and a very important step for the project.

I agree that we should minimize new merges into the main branch during
the stabilization phase, since conflicts around such a large kernel
upgrade can quickly become difficult to manage.

At the same time, I wonder whether we could define a rough
stabilization/review window (for example, around 2 weeks) to give the
community enough time to:

* review the merge,
* run tests on different workloads,
* identify regressions,
* and help resolve the remaining FIXME items.

Meanwhile, to avoid blocking normal community development completely,
perhaps we could temporarily branch from the current main branch (for
example, something like `PG14_ARCHIVE` or another integration branch).
Also, this way can help us manage the new commits for the coming 2.2
release.

New PRs could continue to be merged there during the review window,
and after the PG16 branch stabilizes, those commits could be
selectively cherry-picked or forward-ported into the upgraded branch.

I think this may help balance: stabilization of the PG16 merge, and
continued community contribution flow.

Of course, reviews on the current PG16 merge PR can continue in
parallel. How about this?


Best,
Dianjin Wang

On Sat, May 23, 2026 at 4:30 AM Jinbao Chen <ch...@gmail.com> wrote:
>
> Hi all,
>
> I am very glad that we have finally completed the merge of Postgres 15 and
> 16, and everyone is more
>
> than welcome to review it.Here are some of the new features:
>
> Key features and changes, sorted by importance:
>
>    1.
>
>    MERGE command
>    -
>
>       SQL-standard MERGE for INSERT/UPDATE/DELETE in a single statement.
>       -
>
>       ruleutils decompilation, PlaceHolderVar support in actions
>       -
>
>       Fixes for partitioned tables, cross-partition triggers, RLS,
>       -
>
>       EvalPlanQual, self-modified tuples, pg_stat_statements
>       2.
>
>    Logical replication enhancements
>    -
>
>       Built-in support for prepared transactions (2PC)
>       -
>
>       Enable two-phase via replication protocol
>       -
>
>       Streaming changes after speculative aborts
>       -
>
>       New pg_create_subscription predefined role
>       -
>
>       Parallel apply workers (PG 16)
>       -
>
>       Row/column filtering, schema-level publication (PG 15)
>       -
>
>       Critical fix for data loss in logical replication
>       -
>
>       Slot invalidation, snapshot, and memory leak fixes
>       3.
>
>    SQL/JSON
>    -
>
>       IS JSON predicate
>       -
>
>       Standard JSON constructor functions (json_array, json_object,
>       json_scalar, json_serialize)
>       -
>
>       Auto-generated query jumbling via gen_node_support.pl
>       -
>
>       Fix json_array() subquery double transformation
>       4.
>
>    WAL and storage subsystem
>    -
>
>       LZ4 compression for full-page writes (FPW)
>       -
>
>       Custom WAL resource managers
>       -
>
>       Skip WAL recycling/preallocation during archive recovery
>       -
>
>       XLOG_FPI_FOR_HINT honors full_page_writes setting
>       -
>
>       Direct I/O support on macOS
>       -
>
>       Buffer manager infrastructure refactor for faster relation extension
>       -
>
>       New smgrzeroextend(), FileZero(), FileFallocate()
>       -
>
>       Remove HeapBitmapScan skip_fetch optimization (correctness issue)
>       -
>
>       WAL/Recovery separation: xlogrecovery.c, xlogprefetcher.c (PG 15)
>       -
>
>       Backup sink architecture (PG 15)
>       5.
>
>    Query optimizer / executor
>    Performance:
>    -
>
>       Hash table acceleration for NOT IN(values)
>       -
>
>       Datum sorts for single-column sorts
>       -
>
>       Result Cache renamed to Memoize with ongoing fixes
>       -
>
>       Parallel Hash Full Join
>       -
>
>       Reduced planning cost for deeply-nested views
>       -
>
>       Fewer pallocs when building partition bounds
>       -
>
>       Outer join optimization enhancement (PG 16)
>       -
>
>       Symmetric hash join optimization (PG 16)
>       Critical fixes:
>       -
>
>       Planner failure to identify multiple hashable ScalarArrayOpExprs
>       -
>
>       Consistent whole-row Var construction in parsing and planning
>       -
>
>       WindowAgg evaluation crash
>       -
>
>       WITH RECURSIVE UNION assert failure
>       -
>
>       ORDER BY / DISTINCT aggregates with FILTER
>       -
>
>       setrefs.c missing expression processing on prune steps
>       -
>
>       Parallel Hash Join extreme skew detection
>       6.
>
>    pgstat monitoring enhancements
>    pgstat shared memory rewrite (PG 15):
>    -
>
>       Stats collector process removed; stats now in shared memory
>       -
>
>       Monolithic pgstat.c split into 14 files under utils/activity/
>       pg_stat_io (PG 16 new view):
>       -
>
>       Detailed I/O statistics: shared buffer hits, I/O times, writeback
>       pg_stat_statements:
>       -
>
>       JIT counters, temp file block I/O timing
>       -
>
>       Utility query string normalization, MERGE support
>       -
>
>       32-bit integer overflow fix
>       Other:
>       -
>
>       pg_stat_wal time accumulation as instr_time
>       -
>
>       Macro-generated pg_stat_get*() functions for tables and databases
>       -
>
>       Enhanced pg_stat_reset_single_table_counters
>       -
>
>       SP-GiST index scans counted in pg_stat
>       -
>
>       New test helpers: pg_stat_force_next_flush(), pg_stat_have_stats()
>       7.
>
>    libpq and client protocol
>    -
>
>       New PQsendFlushRequest
>       -
>
>       Pipeline mode state machine fix
>       -
>
>       SASL code refactored to generic interface
>       -
>
>       Escape function fixes for invalid encoding data (security)
>       -
>
>       PQescapeLiteral()/PQescapeIdentifier() length handling fix
>       -
>
>       New pg_encoding_set_invalid()
>       -
>
>       Build-time check that libpq doesn't call exit()/abort()
>       8.
>
>    Security and privilege model
>    -
>
>       CREATEROLE privilege restrictions (major security improvement)
>       -
>
>       New GUCs: createrole_self_grant, reserved_connections
>       -
>
>       New predefined roles: pg_maintain, pg_create_subscription
>       -
>
>       Non-superuser predefined roles for vacuum/analyze
>       -
>
>       Revoke PUBLIC CREATE from public schema (now owned by
>       pg_database_owner)
>       -
>
>       Security invoker views (SECURITY INVOKER)
>       -
>
>       session_authorization and role interaction fixes
>       -
>
>       scram_SaltedPassword() integer overflow fix
>       9.
>
>    pg_dump / pg_upgrade / pg_basebackup toolchain
>    pg_dump:
>    -
>
>       Generic compression API, zstd support, LZ4 frame-only format
>       pg_basebackup:
>       -
>
>       Extended compression options, server-side compression with -Fp
>       -
>
>       Client-side LZ4 decompression, parallel zstd compression
>       pg_upgrade:
>       -
>
>       Fix unintentional 'NULL' string literal
>       -
>
>       Fix XMLSERIALIZE(NO INDENT) cross-version upgrade
>       -
>
>       pg_dumpall handling of dangling OIDs in pg_auth_members
>       10.
>
>    Partitioned table improvements
>    -
>
>       Self-referencing FKs in partitioned tables
>       -
>
>       Detach partition with top-level FK fix
>       -
>
>       Reset relhassubclass on ATTACH
>       -
>
>       Trigger rename consistency, preserve firing state on clone
>       -
>
>       Disallow partitionwise join/grouping on collation mismatch
>       11.
>
>    ICU and collation
>    -
>
>       Build ICU support by default
>       -
>
>       initdb uses uloc_getDefault()
>       -
>
>       CREATE DATABASE LOCALE applies to all collation providers
>       12.
>
>    Node support function auto-generation (FIXME)
>    -
>
>       gen_node_support.pl auto-generates
>       copyfuncs/equalfuncs/outfuncs/readfuncs
>       -
>
>       Query jumbling code auto-generation
>       -
>
>       NodeTag ABI stability check
>       13.
>
>    Global renames and structural changes
>    -
>
>       RelFileNode -> RelFileLocator (pervasive rename across hundreds of
>       files)
>       -
>
>       GUC system split: guc.c -> guc.c + guc_tables.c + guc_funcs.c
>       -
>
>       varatt.h separated from postgres.h
>       -
>
>       Test framework: PostgresNode.pm -> PostgreSQL::Test::Cluster
>       14.
>
>    SQL types and functions
>    -
>
>       Numeric scale allows negative or greater than precision
>       -
>
>       New ANY_VALUE aggregate function
>       -
>
>       unnest(multirange), range_agg with multirange inputs
>       -
>
>       pg_size_pretty/pg_size_bytes support petabytes
>       -
>
>       ALTER TABLE SET ACCESS METHOD
>       -
>
>       SYSTEM_USER function
>       -
>
>       numeric_mul() overflow fix
>       15.
>
>    psql improvements
>    -
>
>       PSQL_WATCH_PAGER for \watch command
>       -
>
>       New \drg command for role grants
>       -
>
>       \copy from sends data in larger chunks
>       -
>
>       pg_waldump --rmgr multiple specification
>       16.
>
>    Critical data corruption and crash fixes
>    -
>
>       Fix data corruption when relation truncation fails
>       -
>
>       Fail instead of corrupting page header on non-LP_NORMAL TID update
>       -
>
>       Fix unsafe BufferDescriptors access
>       -
>
>       GB18030 SIGSEGV from out-of-bounds read
>       -
>
>       Snowball stemmer null pointer dereference after OOM
>       -
>
>       Rare standby assertion failure on primary restart
>       -
>
>       catcache invalidation during list entry construction
>       17.
>
>    Vacuum / Autovacuum
>    -
>
>       Parallel VACUUM (PG 16, vacuumparallel.c new file)
>       -
>
>       ON COMMIT DELETE ROWS avoids ERROR after relhassubclass=f
>       -
>
>       Use WaitLatch() instead of pg_usleep() at end-of-vacuum truncation
>       -
>
>       Prevent numeric overflow in parallel numeric aggregates
>       -
>
>       ANALYZE preserves relhasindex for partitioned tables
>
>
> Currently, there are still some features that are not fully functional yet.
> We have left some "FIXME" tags,
>
> which will be fixed one after another in the coming weeks. We will create a
> feature for each "FIXME" in
>
> the project board, and anyone is welcome to help fix them:
> https://github.com/orgs/apache/projects/497
>
>
> Since the amount of code in this merge is massive, handling conflicts will
> be very troublesome if new code
>
> is merged into the main branch. Therefore, please temporarily pause merging
> any code for the next few days.
>
>
> Below is the list of contributors to this merge.
>
> Jinbao Chen <ch...@gmail.com>
>
> liushengsong <ls...@gmail.com>
>
> reshke <re...@double.cloud>
>
> Hao Wu <gf...@gmail.com>
>
> Jianghua.yjh <yj...@gmail.com>
>
> Dianjin Wang <wa...@gmail.com>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: dev-help@cloudberry.apache.org

Re: The pull request of merge postgres 15 and 16 is created

[Leonid Borchuk <le...@gmail.com>]

Hi all,

+1,

There is no other way to make such a big change. Let's merge it and then
adapt all other work to the new kernel.

For some time, development may be carried out in two branches at the same
time. I think this is better than postponing and complicating the merge of
the new core even more.

On Tue, May 26, 2026 at 8:20 AM Jinbao Chen <ch...@gmail.com>
wrote:

> Great,
>
> Please feel free to reach out if you encounter any rebase issues after the
> merge—I’m very glad to assist!
>
> On Mon, May 25, 2026 at 11:44 PM Dianjin Wang <wa...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > Thanks everyone for the discussion.
> >
> > At this point, it seems the general consensus is leaning toward moving
> > forward with merging the PG16 upgrade into the main branch soon. I
> > respect and support the community consensus process here - disagree
> > and commit, so let’s move forward together.
> >
> > That said, before the final merge operation happens, I still think it
> > would be beneficial to leave a little more time (perhaps 1~2 more
> > days) so contributors from other time zones also have a fair
> > opportunity to participate in the discussion and review process.
> >
> > Also, in the parallel 2.2 release discussion thread started by Leonid,
> > there was a suggestion to land key 2.2 features into the 2.x branch
> > first. I personally support this direction. I think it addresses many
> > of the concerns I mentioned earlier around transition coordination and
> > ongoing in-flight work.
> >
> > With the 2.2 release work continuing for more time, I now agree that
> > moving the PG16 kernel upgrade into the main branch sooner probably
> > makes more sense overall.
> >
> > Before the merge happens, I think there are still several preparation
> > steps that would help make the transition smoother (I’m happy to help
> > with these tasks):
> >
> > * Create a copy branch from the current main branch (for example
> > `PG14_ARCHIVE`) to mirror the existing PG14-based code line.
> > * Apply a similar strategy to related ecosystem repositories where
> > appropriate, including PXF and cloudberry-backup.
> > * Clearly document the transition strategy for contributors, including
> > which branches should receive PG14 fixes versus PG16-targeted
> > development (can do after the PG16 merging).
> >
> > I think these steps can help reduce disruption during the transition
> > period while still allowing us to move the PG16 work forward.
> >
> > Thanks again to everyone driving this huge effort.
> >
> >
> > Best,
> > Dianjin Wang
> >
> > On Tue, May 26, 2026 at 11:05 AM Jinbao Chen <ch...@gmail.com>
> > wrote:
> > >
> > > When a new PR is merged into the main branch, the feature branch
> should,
> > in
> > > theory,
> > > rebase onto the main branch. However, because this specific merge PR is
> > > massive—containing
> > > all the code for Postgres 15 and 16 along with numerous bug fixes—a
> > rebase
> > > has become
> > > practically impossible. Consequently, the merge PR must instead merge
> the
> > > main branch into
> > > itself, which will create an additional merge commit on top of the
> > Postgres
> > > 16 merge. Eliminating
> > > this redundant merge commit requires highly complex Git operations,
> which
> > > takes time and introduces risk.
> > >
> > > Other PRs do not suffer from this issue. They can follow the standard
> > > workflow and rebase normally,
> > > which is much simpler and less risky than handling the merge PR.
> > >
> > > At the same time, if we choose to wait two to three weeks for existing
> > PRs
> > > to merge, new
> > > PRs will inevitably keep coming in anyway. What, then, would be the
> point
> > > of waiting?
> > >
> > > On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <wa...@gmail.com>
> > wrote:
> > >
> > > > Hi Jinbao, all,
> > > >
> > > > First of all, I completely understand the concern about keeping the
> > main
> > > > branch blocked for too long, especially considering the size of this
> > work
> > > > and the complexity of continuously rebasing such a large upgrade
> > branch. (I
> > > > believe some PRs an be merged by now,  but still not somehow).
> > > >
> > > > However, I think this transition is not only about merging the
> > PostgreSQL
> > > > 16 kernel into the main repository itself, but also about preparing
> the
> > > > broader Cloudberry ecosystem for the transition from PG14 to PG16.
> > > >
> > > > For example, several ecosystem components and CI pipelines are
> > currently
> > > > still tightly coupled with the existing main branch, including: PXF,
> > > > cloudberry-backup and potentially other downstream components.
> > > >
> > > > Some time may be needed for contributors to evaluate how we can
> support
> > > > both PG14 and PG16 during the transition period.
> > > >
> > > > Also, the past three days included the weekend, and according to
> normal
> > > > Apache community practice, review windows around weekends are usually
> > > > considered differently since many contributors may be offline or on
> > > > vacation.
> > > >
> > > > Another concern is that we are also about to begin discussions around
> > the
> > > > 2.2 release (Leonid will send a discussion email later maybe), while
> > at the
> > > > same time there are still many active PRs currently under review on
> > top of
> > > > the PG14-based main branch — especially around Orca, PAX, Planner,
> and
> > > > related areas. My concern is that once the main branch fully switches
> > to
> > > > the PG16 kernel, many of these existing PRs may will not be simply
> > > > cherry-picked from the main to the 2.x release. I think it indeed
> > needs a
> > > > good balance to handle with this situation. Everyone handles the
> > rebased
> > > > work for PG16, or we do the rebase only once in the PG16 PR.
> > > >
> > > > Yesterday I had a brief private discussion with Max, my opinions (no
> > > > decision, just sharing):
> > > >
> > > >
> > > >    -
> > > >
> > > >    allowing a transition/review window (for example around 2–3
> weeks),
> > > >    -
> > > >
> > > >    accelerating review and merge of the currently active PG14-based
> PRs
> > > >    during this period,
> > > >    -
> > > >
> > > >    and then temporarily locking the main branch and performing a
> final
> > > >    rebase/synchronization of the PG16 branch once - You don’t need to
> > > > repeatly
> > > >    rebase to catch up the main’s changes
> > > >
> > > > I think this could help:
> > > >
> > > >
> > > >    -
> > > >
> > > >    reduce repeated rebase work for the PG16 PR,
> > > >    -
> > > >
> > > >    give ecosystem components some reaction/adaptation time, help us
> > > >    coordinate with our next 2.x minor release,
> > > >    -
> > > >
> > > >    and help existing contributors land their in-flight work before
> the
> > > >    kernel transition fully happens.
> > > >
> > > > A good strategy will help us. Just sharing these thoughts for
> > discussion.
> > > > We can continue the discussion here, or an open meeting on this.
> Thanks
> > > > again for driving this huge effort forward.
> > > >
> > > > Best,
> > > > Dianjin Wang
> > > >
> > > > Jinbao Chen <ch...@gmail.com>于2026年5月26日 周二01:27写道：
> > > >
> > > > > Hi all,
> > > > > It has been three days since the PR was submitted. I intend to
> merge
> > it
> > > > > into the main branch today.
> > > > > Why I chose not to wait any longer:
> > > > > Firstly, we cannot allow the main trunk to be blocked for an
> extended
> > > > > period.
> > > > > Secondly, the sheer size of this PR makes a thorough and effective
> > review
> > > > > impossible.
> > > > >
> > > > > After merging, we will start fixing the FIXMEs. I am currently
> > sorting
> > > > them
> > > > > out and converting them
> > > > > into features in project
> https://github.com/orgs/apache/projects/497
> > > > >
> > > > > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <
> > reshkekirill@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > On Mon, 25 May 2026 at 08:44, Zhang Mingli <avamingli@apache.org
> >
> > > > wrote:
> > > > > > >I think we should go ahead and merge it in.
> > > > > >
> > > > > > +1
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Kirill Reshke
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > > > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > For additional commands, e-mail: dev-help@cloudberry.apache.org
> >
> >
>

Re: The pull request of merge postgres 15 and 16 is created

[Jinbao Chen <ch...@gmail.com>]

Great,

Please feel free to reach out if you encounter any rebase issues after the
merge—I’m very glad to assist!

On Mon, May 25, 2026 at 11:44 PM Dianjin Wang <wa...@gmail.com> wrote:

> Hi all,
>
> Thanks everyone for the discussion.
>
> At this point, it seems the general consensus is leaning toward moving
> forward with merging the PG16 upgrade into the main branch soon. I
> respect and support the community consensus process here - disagree
> and commit, so let’s move forward together.
>
> That said, before the final merge operation happens, I still think it
> would be beneficial to leave a little more time (perhaps 1~2 more
> days) so contributors from other time zones also have a fair
> opportunity to participate in the discussion and review process.
>
> Also, in the parallel 2.2 release discussion thread started by Leonid,
> there was a suggestion to land key 2.2 features into the 2.x branch
> first. I personally support this direction. I think it addresses many
> of the concerns I mentioned earlier around transition coordination and
> ongoing in-flight work.
>
> With the 2.2 release work continuing for more time, I now agree that
> moving the PG16 kernel upgrade into the main branch sooner probably
> makes more sense overall.
>
> Before the merge happens, I think there are still several preparation
> steps that would help make the transition smoother (I’m happy to help
> with these tasks):
>
> * Create a copy branch from the current main branch (for example
> `PG14_ARCHIVE`) to mirror the existing PG14-based code line.
> * Apply a similar strategy to related ecosystem repositories where
> appropriate, including PXF and cloudberry-backup.
> * Clearly document the transition strategy for contributors, including
> which branches should receive PG14 fixes versus PG16-targeted
> development (can do after the PG16 merging).
>
> I think these steps can help reduce disruption during the transition
> period while still allowing us to move the PG16 work forward.
>
> Thanks again to everyone driving this huge effort.
>
>
> Best,
> Dianjin Wang
>
> On Tue, May 26, 2026 at 11:05 AM Jinbao Chen <ch...@gmail.com>
> wrote:
> >
> > When a new PR is merged into the main branch, the feature branch should,
> in
> > theory,
> > rebase onto the main branch. However, because this specific merge PR is
> > massive—containing
> > all the code for Postgres 15 and 16 along with numerous bug fixes—a
> rebase
> > has become
> > practically impossible. Consequently, the merge PR must instead merge the
> > main branch into
> > itself, which will create an additional merge commit on top of the
> Postgres
> > 16 merge. Eliminating
> > this redundant merge commit requires highly complex Git operations, which
> > takes time and introduces risk.
> >
> > Other PRs do not suffer from this issue. They can follow the standard
> > workflow and rebase normally,
> > which is much simpler and less risky than handling the merge PR.
> >
> > At the same time, if we choose to wait two to three weeks for existing
> PRs
> > to merge, new
> > PRs will inevitably keep coming in anyway. What, then, would be the point
> > of waiting?
> >
> > On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <wa...@gmail.com>
> wrote:
> >
> > > Hi Jinbao, all,
> > >
> > > First of all, I completely understand the concern about keeping the
> main
> > > branch blocked for too long, especially considering the size of this
> work
> > > and the complexity of continuously rebasing such a large upgrade
> branch. (I
> > > believe some PRs an be merged by now,  but still not somehow).
> > >
> > > However, I think this transition is not only about merging the
> PostgreSQL
> > > 16 kernel into the main repository itself, but also about preparing the
> > > broader Cloudberry ecosystem for the transition from PG14 to PG16.
> > >
> > > For example, several ecosystem components and CI pipelines are
> currently
> > > still tightly coupled with the existing main branch, including: PXF,
> > > cloudberry-backup and potentially other downstream components.
> > >
> > > Some time may be needed for contributors to evaluate how we can support
> > > both PG14 and PG16 during the transition period.
> > >
> > > Also, the past three days included the weekend, and according to normal
> > > Apache community practice, review windows around weekends are usually
> > > considered differently since many contributors may be offline or on
> > > vacation.
> > >
> > > Another concern is that we are also about to begin discussions around
> the
> > > 2.2 release (Leonid will send a discussion email later maybe), while
> at the
> > > same time there are still many active PRs currently under review on
> top of
> > > the PG14-based main branch — especially around Orca, PAX, Planner, and
> > > related areas. My concern is that once the main branch fully switches
> to
> > > the PG16 kernel, many of these existing PRs may will not be simply
> > > cherry-picked from the main to the 2.x release. I think it indeed
> needs a
> > > good balance to handle with this situation. Everyone handles the
> rebased
> > > work for PG16, or we do the rebase only once in the PG16 PR.
> > >
> > > Yesterday I had a brief private discussion with Max, my opinions (no
> > > decision, just sharing):
> > >
> > >
> > >    -
> > >
> > >    allowing a transition/review window (for example around 2–3 weeks),
> > >    -
> > >
> > >    accelerating review and merge of the currently active PG14-based PRs
> > >    during this period,
> > >    -
> > >
> > >    and then temporarily locking the main branch and performing a final
> > >    rebase/synchronization of the PG16 branch once - You don’t need to
> > > repeatly
> > >    rebase to catch up the main’s changes
> > >
> > > I think this could help:
> > >
> > >
> > >    -
> > >
> > >    reduce repeated rebase work for the PG16 PR,
> > >    -
> > >
> > >    give ecosystem components some reaction/adaptation time, help us
> > >    coordinate with our next 2.x minor release,
> > >    -
> > >
> > >    and help existing contributors land their in-flight work before the
> > >    kernel transition fully happens.
> > >
> > > A good strategy will help us. Just sharing these thoughts for
> discussion.
> > > We can continue the discussion here, or an open meeting on this. Thanks
> > > again for driving this huge effort forward.
> > >
> > > Best,
> > > Dianjin Wang
> > >
> > > Jinbao Chen <ch...@gmail.com>于2026年5月26日 周二01:27写道：
> > >
> > > > Hi all,
> > > > It has been three days since the PR was submitted. I intend to merge
> it
> > > > into the main branch today.
> > > > Why I chose not to wait any longer:
> > > > Firstly, we cannot allow the main trunk to be blocked for an extended
> > > > period.
> > > > Secondly, the sheer size of this PR makes a thorough and effective
> review
> > > > impossible.
> > > >
> > > > After merging, we will start fixing the FIXMEs. I am currently
> sorting
> > > them
> > > > out and converting them
> > > > into features in project https://github.com/orgs/apache/projects/497
> > > >
> > > > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <
> reshkekirill@gmail.com>
> > > > wrote:
> > > >
> > > > > On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org>
> > > wrote:
> > > > > >I think we should go ahead and merge it in.
> > > > >
> > > > > +1
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Kirill Reshke
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> For additional commands, e-mail: dev-help@cloudberry.apache.org
>
>

Re: The pull request of merge postgres 15 and 16 is created

[Jinbao Chen <ch...@gmail.com>]

Hi Kirill,

I think only cherry-pick CVE fixes is fine.

But I would suggest it's better to wait until REL_3_STABLE is created
before we bring in any code, even
CVE fixes.

In order to streamline the postgres code upgrade process , I suggest that
the cloudberry main
branch should exclusively merge from the postgres master branch. Any
additional code from
postgres stable branches should be merged into the corresponding cloudberry
stable branches.

Consider a scenario: our current Postgres core version is 14.14, and we are
trying to merge up
to 16.9. Generally, we want any changes in Postgres 16 to automatically
override the Postgres 14
code without causing conflicts. However, since the release date of 14.14
might actually be later
than 16.9, it could lead to unexpected conflicts or incorrect automatic
merges. If we maintain a
strictly linear progression for the Postgres core code, conflicts will only
occur in places where
both Cloudberry and Postgres have modified the same lines.




On Fri, May 29, 2026 at 2:29 PM Kirill Reshke <re...@gmail.com>
wrote:

> Sure, let's create a 16.9 -> 16.14 + migration project.
> Also, I think it's important to backport all CVE fixes from 16.10,
> 16.11, 16.12, 16.13 & 16.14 urgently (like here[0]), and then
> backport all other patches in a lazy way.
>
> Maybe "urgently" is not very correct term for this, but I think safety
> first here, to ensure we never miss something important once cbdb over
> pg16 will be released
>
>
> [0] https://github.com/apache/cloudberry/pull/1773
>
> On Fri, 29 May 2026 at 18:47, Dianjin Wang <wa...@gmail.com> wrote:
> >
> > Hi all,
> >
> > One additional thought regarding the longer-term maintenance strategy
> > after the PG16 merge stabilization work.
> >
> > Since the current upgrade work brings Apache Cloudberry to PostgreSQL
> > 16.9, I wonder whether, after the FIXME items and stabilization work
> > are largely completed, we should consider continuing to roll forward
> > within the PostgreSQL 16.x series (for example toward newer upstream
> > minor releases such as 16.14 or later), before eventually starting a
> > future PG18 upgrade cycle.
> >
> > Over the past year, while the PG14 → PG16 merge work was ongoing,
> > PostgreSQL upstream has continued releasing additional 16.x minor
> > updates containing bug fixes, stability improvements, and
> > security-related fixes.
> >
> > I think continuing to track newer PostgreSQL 16.x minor releases
> > incrementally may provide several benefits:
> > * Reduce long-term divergence from PostgreSQL upstream.
> > * Avoid accumulating another large maintenance gap.
> > * Make future major-version upgrades easier and more incremental.
> > * Help establish a more continuous upstream synchronization model for
> > Cloudberry, rather than large periodic jumps. I think a rolling-update
> > style upstream synchronization approach may help the project evolve
> > more incrementally over time.
> >
> > Of course, I think stabilization and FIXME resolution should remain
> > the first priority after the current merge lands. But once things
> > become more stable, this may be a worthwhile direction for the
> > community to consider.
> >
> > Just sharing this as a future maintenance thought for discussion.
> >
> > Best,
> > Dianjin Wang
> >
> > On Tue, May 26, 2026 at 10:16 PM Kirill Reshke <re...@gmail.com>
> wrote:
> > >
> > > Okay, so if I'm reading this correctly it's fine if I merge
> > > https://github.com/apache/cloudberry/pull/1736 today, so we will be
> having
> > > all viral fixes is current main.
> > > I can also take an effort of merging this into to-be-main (pg16 merge)
> > > branch, as well as other 16.10-16.14 CVE fixes.
> > > Note that I'm speaking only about security fixes, which is about 50
> > > commits, not whole 16.10-16.14 range
> > >
> > > On Tue, 26 May 2026, 08:44 Dianjin Wang, <wa...@gmail.com>
> wrote:
> > >
> > > > Hi all,
> > > >
> > > > Thanks everyone for the discussion.
> > > >
> > > > At this point, it seems the general consensus is leaning toward
> moving
> > > > forward with merging the PG16 upgrade into the main branch soon. I
> > > > respect and support the community consensus process here - disagree
> > > > and commit, so let’s move forward together.
> > > >
> > > > That said, before the final merge operation happens, I still think it
> > > > would be beneficial to leave a little more time (perhaps 1~2 more
> > > > days) so contributors from other time zones also have a fair
> > > > opportunity to participate in the discussion and review process.
> > > >
> > > > Also, in the parallel 2.2 release discussion thread started by
> Leonid,
> > > > there was a suggestion to land key 2.2 features into the 2.x branch
> > > > first. I personally support this direction. I think it addresses many
> > > > of the concerns I mentioned earlier around transition coordination
> and
> > > > ongoing in-flight work.
> > > >
> > > > With the 2.2 release work continuing for more time, I now agree that
> > > > moving the PG16 kernel upgrade into the main branch sooner probably
> > > > makes more sense overall.
> > > >
> > > > Before the merge happens, I think there are still several preparation
> > > > steps that would help make the transition smoother (I’m happy to help
> > > > with these tasks):
> > > >
> > > > * Create a copy branch from the current main branch (for example
> > > > `PG14_ARCHIVE`) to mirror the existing PG14-based code line.
> > > > * Apply a similar strategy to related ecosystem repositories where
> > > > appropriate, including PXF and cloudberry-backup.
> > > > * Clearly document the transition strategy for contributors,
> including
> > > > which branches should receive PG14 fixes versus PG16-targeted
> > > > development (can do after the PG16 merging).
> > > >
> > > > I think these steps can help reduce disruption during the transition
> > > > period while still allowing us to move the PG16 work forward.
> > > >
> > > > Thanks again to everyone driving this huge effort.
> > > >
> > > >
> > > > Best,
> > > > Dianjin Wang
> > > >
> > > > On Tue, May 26, 2026 at 11:05 AM Jinbao Chen <
> chenjinbao1989@gmail.com>
> > > > wrote:
> > > > >
> > > > > When a new PR is merged into the main branch, the feature branch
> should,
> > > > in
> > > > > theory,
> > > > > rebase onto the main branch. However, because this specific merge
> PR is
> > > > > massive—containing
> > > > > all the code for Postgres 15 and 16 along with numerous bug fixes—a
> > > > rebase
> > > > > has become
> > > > > practically impossible. Consequently, the merge PR must instead
> merge the
> > > > > main branch into
> > > > > itself, which will create an additional merge commit on top of the
> > > > Postgres
> > > > > 16 merge. Eliminating
> > > > > this redundant merge commit requires highly complex Git
> operations, which
> > > > > takes time and introduces risk.
> > > > >
> > > > > Other PRs do not suffer from this issue. They can follow the
> standard
> > > > > workflow and rebase normally,
> > > > > which is much simpler and less risky than handling the merge PR.
> > > > >
> > > > > At the same time, if we choose to wait two to three weeks for
> existing
> > > > PRs
> > > > > to merge, new
> > > > > PRs will inevitably keep coming in anyway. What, then, would be
> the point
> > > > > of waiting?
> > > > >
> > > > > On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <
> wangdianjin@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Hi Jinbao, all,
> > > > > >
> > > > > > First of all, I completely understand the concern about keeping
> the
> > > > main
> > > > > > branch blocked for too long, especially considering the size of
> this
> > > > work
> > > > > > and the complexity of continuously rebasing such a large upgrade
> > > > branch. (I
> > > > > > believe some PRs an be merged by now,  but still not somehow).
> > > > > >
> > > > > > However, I think this transition is not only about merging the
> > > > PostgreSQL
> > > > > > 16 kernel into the main repository itself, but also about
> preparing the
> > > > > > broader Cloudberry ecosystem for the transition from PG14 to
> PG16.
> > > > > >
> > > > > > For example, several ecosystem components and CI pipelines are
> > > > currently
> > > > > > still tightly coupled with the existing main branch, including:
> PXF,
> > > > > > cloudberry-backup and potentially other downstream components.
> > > > > >
> > > > > > Some time may be needed for contributors to evaluate how we can
> support
> > > > > > both PG14 and PG16 during the transition period.
> > > > > >
> > > > > > Also, the past three days included the weekend, and according to
> normal
> > > > > > Apache community practice, review windows around weekends are
> usually
> > > > > > considered differently since many contributors may be offline or
> on
> > > > > > vacation.
> > > > > >
> > > > > > Another concern is that we are also about to begin discussions
> around
> > > > the
> > > > > > 2.2 release (Leonid will send a discussion email later maybe),
> while
> > > > at the
> > > > > > same time there are still many active PRs currently under review
> on
> > > > top of
> > > > > > the PG14-based main branch — especially around Orca, PAX,
> Planner, and
> > > > > > related areas. My concern is that once the main branch fully
> switches
> > > > to
> > > > > > the PG16 kernel, many of these existing PRs may will not be
> simply
> > > > > > cherry-picked from the main to the 2.x release. I think it indeed
> > > > needs a
> > > > > > good balance to handle with this situation. Everyone handles the
> > > > rebased
> > > > > > work for PG16, or we do the rebase only once in the PG16 PR.
> > > > > >
> > > > > > Yesterday I had a brief private discussion with Max, my opinions
> (no
> > > > > > decision, just sharing):
> > > > > >
> > > > > >
> > > > > >    -
> > > > > >
> > > > > >    allowing a transition/review window (for example around 2–3
> weeks),
> > > > > >    -
> > > > > >
> > > > > >    accelerating review and merge of the currently active
> PG14-based PRs
> > > > > >    during this period,
> > > > > >    -
> > > > > >
> > > > > >    and then temporarily locking the main branch and performing a
> final
> > > > > >    rebase/synchronization of the PG16 branch once - You don’t
> need to
> > > > > > repeatly
> > > > > >    rebase to catch up the main’s changes
> > > > > >
> > > > > > I think this could help:
> > > > > >
> > > > > >
> > > > > >    -
> > > > > >
> > > > > >    reduce repeated rebase work for the PG16 PR,
> > > > > >    -
> > > > > >
> > > > > >    give ecosystem components some reaction/adaptation time, help
> us
> > > > > >    coordinate with our next 2.x minor release,
> > > > > >    -
> > > > > >
> > > > > >    and help existing contributors land their in-flight work
> before the
> > > > > >    kernel transition fully happens.
> > > > > >
> > > > > > A good strategy will help us. Just sharing these thoughts for
> > > > discussion.
> > > > > > We can continue the discussion here, or an open meeting on this.
> Thanks
> > > > > > again for driving this huge effort forward.
> > > > > >
> > > > > > Best,
> > > > > > Dianjin Wang
> > > > > >
> > > > > > Jinbao Chen <ch...@gmail.com>于2026年5月26日 周二01:27写道：
> > > > > >
> > > > > > > Hi all,
> > > > > > > It has been three days since the PR was submitted. I intend to
> merge
> > > > it
> > > > > > > into the main branch today.
> > > > > > > Why I chose not to wait any longer:
> > > > > > > Firstly, we cannot allow the main trunk to be blocked for an
> extended
> > > > > > > period.
> > > > > > > Secondly, the sheer size of this PR makes a thorough and
> effective
> > > > review
> > > > > > > impossible.
> > > > > > >
> > > > > > > After merging, we will start fixing the FIXMEs. I am currently
> > > > sorting
> > > > > > them
> > > > > > > out and converting them
> > > > > > > into features in project
> https://github.com/orgs/apache/projects/497
> > > > > > >
> > > > > > > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <
> > > > reshkekirill@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Mon, 25 May 2026 at 08:44, Zhang Mingli <
> avamingli@apache.org>
> > > > > > wrote:
> > > > > > > > >I think we should go ahead and merge it in.
> > > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards,
> > > > > > > > Kirill Reshke
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> dev-unsubscribe@cloudberry.apache.org
> > > > > > > > For additional commands, e-mail:
> dev-help@cloudberry.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > For additional commands, e-mail: dev-help@cloudberry.apache.org
> >
>
>
> --
> Best regards,
> Kirill Reshke
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> For additional commands, e-mail: dev-help@cloudberry.apache.org
>
>

Re: The pull request of merge postgres 15 and 16 is created

[Kirill Reshke <re...@gmail.com>]

With [0], [1] and [2] we will have all CVE fixes back-patched into main

[0] https://github.com/apache/cloudberry/pull/1794
[1] https://github.com/apache/cloudberry/pull/1793
[2] https://github.com/apache/cloudberry/pull/1811


Will move forward into creating a 16.9 - 16.14 migration project?

On Fri, 29 May 2026 at 23:29, Kirill Reshke <re...@gmail.com> wrote:
>
> Sure, let's create a 16.9 -> 16.14 + migration project.
> Also, I think it's important to backport all CVE fixes from 16.10,
> 16.11, 16.12, 16.13 & 16.14 urgently (like here[0]), and then
> backport all other patches in a lazy way.
>
> Maybe "urgently" is not very correct term for this, but I think safety
> first here, to ensure we never miss something important once cbdb over
> pg16 will be released
>
>
> [0] https://github.com/apache/cloudberry/pull/1773
>
> On Fri, 29 May 2026 at 18:47, Dianjin Wang <wa...@gmail.com> wrote:
> >
> > Hi all,
> >
> > One additional thought regarding the longer-term maintenance strategy
> > after the PG16 merge stabilization work.
> >
> > Since the current upgrade work brings Apache Cloudberry to PostgreSQL
> > 16.9, I wonder whether, after the FIXME items and stabilization work
> > are largely completed, we should consider continuing to roll forward
> > within the PostgreSQL 16.x series (for example toward newer upstream
> > minor releases such as 16.14 or later), before eventually starting a
> > future PG18 upgrade cycle.
> >
> > Over the past year, while the PG14 → PG16 merge work was ongoing,
> > PostgreSQL upstream has continued releasing additional 16.x minor
> > updates containing bug fixes, stability improvements, and
> > security-related fixes.
> >
> > I think continuing to track newer PostgreSQL 16.x minor releases
> > incrementally may provide several benefits:
> > * Reduce long-term divergence from PostgreSQL upstream.
> > * Avoid accumulating another large maintenance gap.
> > * Make future major-version upgrades easier and more incremental.
> > * Help establish a more continuous upstream synchronization model for
> > Cloudberry, rather than large periodic jumps. I think a rolling-update
> > style upstream synchronization approach may help the project evolve
> > more incrementally over time.
> >
> > Of course, I think stabilization and FIXME resolution should remain
> > the first priority after the current merge lands. But once things
> > become more stable, this may be a worthwhile direction for the
> > community to consider.
> >
> > Just sharing this as a future maintenance thought for discussion.
> >
> > Best,
> > Dianjin Wang
> >
> > On Tue, May 26, 2026 at 10:16 PM Kirill Reshke <re...@gmail.com> wrote:
> > >
> > > Okay, so if I'm reading this correctly it's fine if I merge
> > > https://github.com/apache/cloudberry/pull/1736 today, so we will be having
> > > all viral fixes is current main.
> > > I can also take an effort of merging this into to-be-main (pg16 merge)
> > > branch, as well as other 16.10-16.14 CVE fixes.
> > > Note that I'm speaking only about security fixes, which is about 50
> > > commits, not whole 16.10-16.14 range
> > >
> > > On Tue, 26 May 2026, 08:44 Dianjin Wang, <wa...@gmail.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > Thanks everyone for the discussion.
> > > >
> > > > At this point, it seems the general consensus is leaning toward moving
> > > > forward with merging the PG16 upgrade into the main branch soon. I
> > > > respect and support the community consensus process here - disagree
> > > > and commit, so let’s move forward together.
> > > >
> > > > That said, before the final merge operation happens, I still think it
> > > > would be beneficial to leave a little more time (perhaps 1~2 more
> > > > days) so contributors from other time zones also have a fair
> > > > opportunity to participate in the discussion and review process.
> > > >
> > > > Also, in the parallel 2.2 release discussion thread started by Leonid,
> > > > there was a suggestion to land key 2.2 features into the 2.x branch
> > > > first. I personally support this direction. I think it addresses many
> > > > of the concerns I mentioned earlier around transition coordination and
> > > > ongoing in-flight work.
> > > >
> > > > With the 2.2 release work continuing for more time, I now agree that
> > > > moving the PG16 kernel upgrade into the main branch sooner probably
> > > > makes more sense overall.
> > > >
> > > > Before the merge happens, I think there are still several preparation
> > > > steps that would help make the transition smoother (I’m happy to help
> > > > with these tasks):
> > > >
> > > > * Create a copy branch from the current main branch (for example
> > > > `PG14_ARCHIVE`) to mirror the existing PG14-based code line.
> > > > * Apply a similar strategy to related ecosystem repositories where
> > > > appropriate, including PXF and cloudberry-backup.
> > > > * Clearly document the transition strategy for contributors, including
> > > > which branches should receive PG14 fixes versus PG16-targeted
> > > > development (can do after the PG16 merging).
> > > >
> > > > I think these steps can help reduce disruption during the transition
> > > > period while still allowing us to move the PG16 work forward.
> > > >
> > > > Thanks again to everyone driving this huge effort.
> > > >
> > > >
> > > > Best,
> > > > Dianjin Wang
> > > >
> > > > On Tue, May 26, 2026 at 11:05 AM Jinbao Chen <ch...@gmail.com>
> > > > wrote:
> > > > >
> > > > > When a new PR is merged into the main branch, the feature branch should,
> > > > in
> > > > > theory,
> > > > > rebase onto the main branch. However, because this specific merge PR is
> > > > > massive—containing
> > > > > all the code for Postgres 15 and 16 along with numerous bug fixes—a
> > > > rebase
> > > > > has become
> > > > > practically impossible. Consequently, the merge PR must instead merge the
> > > > > main branch into
> > > > > itself, which will create an additional merge commit on top of the
> > > > Postgres
> > > > > 16 merge. Eliminating
> > > > > this redundant merge commit requires highly complex Git operations, which
> > > > > takes time and introduces risk.
> > > > >
> > > > > Other PRs do not suffer from this issue. They can follow the standard
> > > > > workflow and rebase normally,
> > > > > which is much simpler and less risky than handling the merge PR.
> > > > >
> > > > > At the same time, if we choose to wait two to three weeks for existing
> > > > PRs
> > > > > to merge, new
> > > > > PRs will inevitably keep coming in anyway. What, then, would be the point
> > > > > of waiting?
> > > > >
> > > > > On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <wa...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Hi Jinbao, all,
> > > > > >
> > > > > > First of all, I completely understand the concern about keeping the
> > > > main
> > > > > > branch blocked for too long, especially considering the size of this
> > > > work
> > > > > > and the complexity of continuously rebasing such a large upgrade
> > > > branch. (I
> > > > > > believe some PRs an be merged by now,  but still not somehow).
> > > > > >
> > > > > > However, I think this transition is not only about merging the
> > > > PostgreSQL
> > > > > > 16 kernel into the main repository itself, but also about preparing the
> > > > > > broader Cloudberry ecosystem for the transition from PG14 to PG16.
> > > > > >
> > > > > > For example, several ecosystem components and CI pipelines are
> > > > currently
> > > > > > still tightly coupled with the existing main branch, including: PXF,
> > > > > > cloudberry-backup and potentially other downstream components.
> > > > > >
> > > > > > Some time may be needed for contributors to evaluate how we can support
> > > > > > both PG14 and PG16 during the transition period.
> > > > > >
> > > > > > Also, the past three days included the weekend, and according to normal
> > > > > > Apache community practice, review windows around weekends are usually
> > > > > > considered differently since many contributors may be offline or on
> > > > > > vacation.
> > > > > >
> > > > > > Another concern is that we are also about to begin discussions around
> > > > the
> > > > > > 2.2 release (Leonid will send a discussion email later maybe), while
> > > > at the
> > > > > > same time there are still many active PRs currently under review on
> > > > top of
> > > > > > the PG14-based main branch — especially around Orca, PAX, Planner, and
> > > > > > related areas. My concern is that once the main branch fully switches
> > > > to
> > > > > > the PG16 kernel, many of these existing PRs may will not be simply
> > > > > > cherry-picked from the main to the 2.x release. I think it indeed
> > > > needs a
> > > > > > good balance to handle with this situation. Everyone handles the
> > > > rebased
> > > > > > work for PG16, or we do the rebase only once in the PG16 PR.
> > > > > >
> > > > > > Yesterday I had a brief private discussion with Max, my opinions (no
> > > > > > decision, just sharing):
> > > > > >
> > > > > >
> > > > > >    -
> > > > > >
> > > > > >    allowing a transition/review window (for example around 2–3 weeks),
> > > > > >    -
> > > > > >
> > > > > >    accelerating review and merge of the currently active PG14-based PRs
> > > > > >    during this period,
> > > > > >    -
> > > > > >
> > > > > >    and then temporarily locking the main branch and performing a final
> > > > > >    rebase/synchronization of the PG16 branch once - You don’t need to
> > > > > > repeatly
> > > > > >    rebase to catch up the main’s changes
> > > > > >
> > > > > > I think this could help:
> > > > > >
> > > > > >
> > > > > >    -
> > > > > >
> > > > > >    reduce repeated rebase work for the PG16 PR,
> > > > > >    -
> > > > > >
> > > > > >    give ecosystem components some reaction/adaptation time, help us
> > > > > >    coordinate with our next 2.x minor release,
> > > > > >    -
> > > > > >
> > > > > >    and help existing contributors land their in-flight work before the
> > > > > >    kernel transition fully happens.
> > > > > >
> > > > > > A good strategy will help us. Just sharing these thoughts for
> > > > discussion.
> > > > > > We can continue the discussion here, or an open meeting on this. Thanks
> > > > > > again for driving this huge effort forward.
> > > > > >
> > > > > > Best,
> > > > > > Dianjin Wang
> > > > > >
> > > > > > Jinbao Chen <ch...@gmail.com>于2026年5月26日 周二01:27写道：
> > > > > >
> > > > > > > Hi all,
> > > > > > > It has been three days since the PR was submitted. I intend to merge
> > > > it
> > > > > > > into the main branch today.
> > > > > > > Why I chose not to wait any longer:
> > > > > > > Firstly, we cannot allow the main trunk to be blocked for an extended
> > > > > > > period.
> > > > > > > Secondly, the sheer size of this PR makes a thorough and effective
> > > > review
> > > > > > > impossible.
> > > > > > >
> > > > > > > After merging, we will start fixing the FIXMEs. I am currently
> > > > sorting
> > > > > > them
> > > > > > > out and converting them
> > > > > > > into features in project https://github.com/orgs/apache/projects/497
> > > > > > >
> > > > > > > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <
> > > > reshkekirill@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org>
> > > > > > wrote:
> > > > > > > > >I think we should go ahead and merge it in.
> > > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards,
> > > > > > > > Kirill Reshke
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > For additional commands, e-mail: dev-help@cloudberry.apache.org
> >
>
>
> --
> Best regards,
> Kirill Reshke



-- 
Best regards,
Kirill Reshke

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: dev-help@cloudberry.apache.org

Re: The pull request of merge postgres 15 and 16 is created

[Kirill Reshke <re...@gmail.com>]

Sure, let's create a 16.9 -> 16.14 + migration project.
Also, I think it's important to backport all CVE fixes from 16.10,
16.11, 16.12, 16.13 & 16.14 urgently (like here[0]), and then
backport all other patches in a lazy way.

Maybe "urgently" is not very correct term for this, but I think safety
first here, to ensure we never miss something important once cbdb over
pg16 will be released


[0] https://github.com/apache/cloudberry/pull/1773

On Fri, 29 May 2026 at 18:47, Dianjin Wang <wa...@gmail.com> wrote:
>
> Hi all,
>
> One additional thought regarding the longer-term maintenance strategy
> after the PG16 merge stabilization work.
>
> Since the current upgrade work brings Apache Cloudberry to PostgreSQL
> 16.9, I wonder whether, after the FIXME items and stabilization work
> are largely completed, we should consider continuing to roll forward
> within the PostgreSQL 16.x series (for example toward newer upstream
> minor releases such as 16.14 or later), before eventually starting a
> future PG18 upgrade cycle.
>
> Over the past year, while the PG14 → PG16 merge work was ongoing,
> PostgreSQL upstream has continued releasing additional 16.x minor
> updates containing bug fixes, stability improvements, and
> security-related fixes.
>
> I think continuing to track newer PostgreSQL 16.x minor releases
> incrementally may provide several benefits:
> * Reduce long-term divergence from PostgreSQL upstream.
> * Avoid accumulating another large maintenance gap.
> * Make future major-version upgrades easier and more incremental.
> * Help establish a more continuous upstream synchronization model for
> Cloudberry, rather than large periodic jumps. I think a rolling-update
> style upstream synchronization approach may help the project evolve
> more incrementally over time.
>
> Of course, I think stabilization and FIXME resolution should remain
> the first priority after the current merge lands. But once things
> become more stable, this may be a worthwhile direction for the
> community to consider.
>
> Just sharing this as a future maintenance thought for discussion.
>
> Best,
> Dianjin Wang
>
> On Tue, May 26, 2026 at 10:16 PM Kirill Reshke <re...@gmail.com> wrote:
> >
> > Okay, so if I'm reading this correctly it's fine if I merge
> > https://github.com/apache/cloudberry/pull/1736 today, so we will be having
> > all viral fixes is current main.
> > I can also take an effort of merging this into to-be-main (pg16 merge)
> > branch, as well as other 16.10-16.14 CVE fixes.
> > Note that I'm speaking only about security fixes, which is about 50
> > commits, not whole 16.10-16.14 range
> >
> > On Tue, 26 May 2026, 08:44 Dianjin Wang, <wa...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > Thanks everyone for the discussion.
> > >
> > > At this point, it seems the general consensus is leaning toward moving
> > > forward with merging the PG16 upgrade into the main branch soon. I
> > > respect and support the community consensus process here - disagree
> > > and commit, so let’s move forward together.
> > >
> > > That said, before the final merge operation happens, I still think it
> > > would be beneficial to leave a little more time (perhaps 1~2 more
> > > days) so contributors from other time zones also have a fair
> > > opportunity to participate in the discussion and review process.
> > >
> > > Also, in the parallel 2.2 release discussion thread started by Leonid,
> > > there was a suggestion to land key 2.2 features into the 2.x branch
> > > first. I personally support this direction. I think it addresses many
> > > of the concerns I mentioned earlier around transition coordination and
> > > ongoing in-flight work.
> > >
> > > With the 2.2 release work continuing for more time, I now agree that
> > > moving the PG16 kernel upgrade into the main branch sooner probably
> > > makes more sense overall.
> > >
> > > Before the merge happens, I think there are still several preparation
> > > steps that would help make the transition smoother (I’m happy to help
> > > with these tasks):
> > >
> > > * Create a copy branch from the current main branch (for example
> > > `PG14_ARCHIVE`) to mirror the existing PG14-based code line.
> > > * Apply a similar strategy to related ecosystem repositories where
> > > appropriate, including PXF and cloudberry-backup.
> > > * Clearly document the transition strategy for contributors, including
> > > which branches should receive PG14 fixes versus PG16-targeted
> > > development (can do after the PG16 merging).
> > >
> > > I think these steps can help reduce disruption during the transition
> > > period while still allowing us to move the PG16 work forward.
> > >
> > > Thanks again to everyone driving this huge effort.
> > >
> > >
> > > Best,
> > > Dianjin Wang
> > >
> > > On Tue, May 26, 2026 at 11:05 AM Jinbao Chen <ch...@gmail.com>
> > > wrote:
> > > >
> > > > When a new PR is merged into the main branch, the feature branch should,
> > > in
> > > > theory,
> > > > rebase onto the main branch. However, because this specific merge PR is
> > > > massive—containing
> > > > all the code for Postgres 15 and 16 along with numerous bug fixes—a
> > > rebase
> > > > has become
> > > > practically impossible. Consequently, the merge PR must instead merge the
> > > > main branch into
> > > > itself, which will create an additional merge commit on top of the
> > > Postgres
> > > > 16 merge. Eliminating
> > > > this redundant merge commit requires highly complex Git operations, which
> > > > takes time and introduces risk.
> > > >
> > > > Other PRs do not suffer from this issue. They can follow the standard
> > > > workflow and rebase normally,
> > > > which is much simpler and less risky than handling the merge PR.
> > > >
> > > > At the same time, if we choose to wait two to three weeks for existing
> > > PRs
> > > > to merge, new
> > > > PRs will inevitably keep coming in anyway. What, then, would be the point
> > > > of waiting?
> > > >
> > > > On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <wa...@gmail.com>
> > > wrote:
> > > >
> > > > > Hi Jinbao, all,
> > > > >
> > > > > First of all, I completely understand the concern about keeping the
> > > main
> > > > > branch blocked for too long, especially considering the size of this
> > > work
> > > > > and the complexity of continuously rebasing such a large upgrade
> > > branch. (I
> > > > > believe some PRs an be merged by now,  but still not somehow).
> > > > >
> > > > > However, I think this transition is not only about merging the
> > > PostgreSQL
> > > > > 16 kernel into the main repository itself, but also about preparing the
> > > > > broader Cloudberry ecosystem for the transition from PG14 to PG16.
> > > > >
> > > > > For example, several ecosystem components and CI pipelines are
> > > currently
> > > > > still tightly coupled with the existing main branch, including: PXF,
> > > > > cloudberry-backup and potentially other downstream components.
> > > > >
> > > > > Some time may be needed for contributors to evaluate how we can support
> > > > > both PG14 and PG16 during the transition period.
> > > > >
> > > > > Also, the past three days included the weekend, and according to normal
> > > > > Apache community practice, review windows around weekends are usually
> > > > > considered differently since many contributors may be offline or on
> > > > > vacation.
> > > > >
> > > > > Another concern is that we are also about to begin discussions around
> > > the
> > > > > 2.2 release (Leonid will send a discussion email later maybe), while
> > > at the
> > > > > same time there are still many active PRs currently under review on
> > > top of
> > > > > the PG14-based main branch — especially around Orca, PAX, Planner, and
> > > > > related areas. My concern is that once the main branch fully switches
> > > to
> > > > > the PG16 kernel, many of these existing PRs may will not be simply
> > > > > cherry-picked from the main to the 2.x release. I think it indeed
> > > needs a
> > > > > good balance to handle with this situation. Everyone handles the
> > > rebased
> > > > > work for PG16, or we do the rebase only once in the PG16 PR.
> > > > >
> > > > > Yesterday I had a brief private discussion with Max, my opinions (no
> > > > > decision, just sharing):
> > > > >
> > > > >
> > > > >    -
> > > > >
> > > > >    allowing a transition/review window (for example around 2–3 weeks),
> > > > >    -
> > > > >
> > > > >    accelerating review and merge of the currently active PG14-based PRs
> > > > >    during this period,
> > > > >    -
> > > > >
> > > > >    and then temporarily locking the main branch and performing a final
> > > > >    rebase/synchronization of the PG16 branch once - You don’t need to
> > > > > repeatly
> > > > >    rebase to catch up the main’s changes
> > > > >
> > > > > I think this could help:
> > > > >
> > > > >
> > > > >    -
> > > > >
> > > > >    reduce repeated rebase work for the PG16 PR,
> > > > >    -
> > > > >
> > > > >    give ecosystem components some reaction/adaptation time, help us
> > > > >    coordinate with our next 2.x minor release,
> > > > >    -
> > > > >
> > > > >    and help existing contributors land their in-flight work before the
> > > > >    kernel transition fully happens.
> > > > >
> > > > > A good strategy will help us. Just sharing these thoughts for
> > > discussion.
> > > > > We can continue the discussion here, or an open meeting on this. Thanks
> > > > > again for driving this huge effort forward.
> > > > >
> > > > > Best,
> > > > > Dianjin Wang
> > > > >
> > > > > Jinbao Chen <ch...@gmail.com>于2026年5月26日 周二01:27写道：
> > > > >
> > > > > > Hi all,
> > > > > > It has been three days since the PR was submitted. I intend to merge
> > > it
> > > > > > into the main branch today.
> > > > > > Why I chose not to wait any longer:
> > > > > > Firstly, we cannot allow the main trunk to be blocked for an extended
> > > > > > period.
> > > > > > Secondly, the sheer size of this PR makes a thorough and effective
> > > review
> > > > > > impossible.
> > > > > >
> > > > > > After merging, we will start fixing the FIXMEs. I am currently
> > > sorting
> > > > > them
> > > > > > out and converting them
> > > > > > into features in project https://github.com/orgs/apache/projects/497
> > > > > >
> > > > > > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <
> > > reshkekirill@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org>
> > > > > wrote:
> > > > > > > >I think we should go ahead and merge it in.
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Kirill Reshke
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > > > > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> For additional commands, e-mail: dev-help@cloudberry.apache.org
>


-- 
Best regards,
Kirill Reshke

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: dev-help@cloudberry.apache.org

Re: The pull request of merge postgres 15 and 16 is created

[Dianjin Wang <wa...@gmail.com>]

Hi all,

One additional thought regarding the longer-term maintenance strategy
after the PG16 merge stabilization work.

Since the current upgrade work brings Apache Cloudberry to PostgreSQL
16.9, I wonder whether, after the FIXME items and stabilization work
are largely completed, we should consider continuing to roll forward
within the PostgreSQL 16.x series (for example toward newer upstream
minor releases such as 16.14 or later), before eventually starting a
future PG18 upgrade cycle.

Over the past year, while the PG14 → PG16 merge work was ongoing,
PostgreSQL upstream has continued releasing additional 16.x minor
updates containing bug fixes, stability improvements, and
security-related fixes.

I think continuing to track newer PostgreSQL 16.x minor releases
incrementally may provide several benefits:
* Reduce long-term divergence from PostgreSQL upstream.
* Avoid accumulating another large maintenance gap.
* Make future major-version upgrades easier and more incremental.
* Help establish a more continuous upstream synchronization model for
Cloudberry, rather than large periodic jumps. I think a rolling-update
style upstream synchronization approach may help the project evolve
more incrementally over time.

Of course, I think stabilization and FIXME resolution should remain
the first priority after the current merge lands. But once things
become more stable, this may be a worthwhile direction for the
community to consider.

Just sharing this as a future maintenance thought for discussion.

Best,
Dianjin Wang

On Tue, May 26, 2026 at 10:16 PM Kirill Reshke <re...@gmail.com> wrote:
>
> Okay, so if I'm reading this correctly it's fine if I merge
> https://github.com/apache/cloudberry/pull/1736 today, so we will be having
> all viral fixes is current main.
> I can also take an effort of merging this into to-be-main (pg16 merge)
> branch, as well as other 16.10-16.14 CVE fixes.
> Note that I'm speaking only about security fixes, which is about 50
> commits, not whole 16.10-16.14 range
>
> On Tue, 26 May 2026, 08:44 Dianjin Wang, <wa...@gmail.com> wrote:
>
> > Hi all,
> >
> > Thanks everyone for the discussion.
> >
> > At this point, it seems the general consensus is leaning toward moving
> > forward with merging the PG16 upgrade into the main branch soon. I
> > respect and support the community consensus process here - disagree
> > and commit, so let’s move forward together.
> >
> > That said, before the final merge operation happens, I still think it
> > would be beneficial to leave a little more time (perhaps 1~2 more
> > days) so contributors from other time zones also have a fair
> > opportunity to participate in the discussion and review process.
> >
> > Also, in the parallel 2.2 release discussion thread started by Leonid,
> > there was a suggestion to land key 2.2 features into the 2.x branch
> > first. I personally support this direction. I think it addresses many
> > of the concerns I mentioned earlier around transition coordination and
> > ongoing in-flight work.
> >
> > With the 2.2 release work continuing for more time, I now agree that
> > moving the PG16 kernel upgrade into the main branch sooner probably
> > makes more sense overall.
> >
> > Before the merge happens, I think there are still several preparation
> > steps that would help make the transition smoother (I’m happy to help
> > with these tasks):
> >
> > * Create a copy branch from the current main branch (for example
> > `PG14_ARCHIVE`) to mirror the existing PG14-based code line.
> > * Apply a similar strategy to related ecosystem repositories where
> > appropriate, including PXF and cloudberry-backup.
> > * Clearly document the transition strategy for contributors, including
> > which branches should receive PG14 fixes versus PG16-targeted
> > development (can do after the PG16 merging).
> >
> > I think these steps can help reduce disruption during the transition
> > period while still allowing us to move the PG16 work forward.
> >
> > Thanks again to everyone driving this huge effort.
> >
> >
> > Best,
> > Dianjin Wang
> >
> > On Tue, May 26, 2026 at 11:05 AM Jinbao Chen <ch...@gmail.com>
> > wrote:
> > >
> > > When a new PR is merged into the main branch, the feature branch should,
> > in
> > > theory,
> > > rebase onto the main branch. However, because this specific merge PR is
> > > massive—containing
> > > all the code for Postgres 15 and 16 along with numerous bug fixes—a
> > rebase
> > > has become
> > > practically impossible. Consequently, the merge PR must instead merge the
> > > main branch into
> > > itself, which will create an additional merge commit on top of the
> > Postgres
> > > 16 merge. Eliminating
> > > this redundant merge commit requires highly complex Git operations, which
> > > takes time and introduces risk.
> > >
> > > Other PRs do not suffer from this issue. They can follow the standard
> > > workflow and rebase normally,
> > > which is much simpler and less risky than handling the merge PR.
> > >
> > > At the same time, if we choose to wait two to three weeks for existing
> > PRs
> > > to merge, new
> > > PRs will inevitably keep coming in anyway. What, then, would be the point
> > > of waiting?
> > >
> > > On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <wa...@gmail.com>
> > wrote:
> > >
> > > > Hi Jinbao, all,
> > > >
> > > > First of all, I completely understand the concern about keeping the
> > main
> > > > branch blocked for too long, especially considering the size of this
> > work
> > > > and the complexity of continuously rebasing such a large upgrade
> > branch. (I
> > > > believe some PRs an be merged by now,  but still not somehow).
> > > >
> > > > However, I think this transition is not only about merging the
> > PostgreSQL
> > > > 16 kernel into the main repository itself, but also about preparing the
> > > > broader Cloudberry ecosystem for the transition from PG14 to PG16.
> > > >
> > > > For example, several ecosystem components and CI pipelines are
> > currently
> > > > still tightly coupled with the existing main branch, including: PXF,
> > > > cloudberry-backup and potentially other downstream components.
> > > >
> > > > Some time may be needed for contributors to evaluate how we can support
> > > > both PG14 and PG16 during the transition period.
> > > >
> > > > Also, the past three days included the weekend, and according to normal
> > > > Apache community practice, review windows around weekends are usually
> > > > considered differently since many contributors may be offline or on
> > > > vacation.
> > > >
> > > > Another concern is that we are also about to begin discussions around
> > the
> > > > 2.2 release (Leonid will send a discussion email later maybe), while
> > at the
> > > > same time there are still many active PRs currently under review on
> > top of
> > > > the PG14-based main branch — especially around Orca, PAX, Planner, and
> > > > related areas. My concern is that once the main branch fully switches
> > to
> > > > the PG16 kernel, many of these existing PRs may will not be simply
> > > > cherry-picked from the main to the 2.x release. I think it indeed
> > needs a
> > > > good balance to handle with this situation. Everyone handles the
> > rebased
> > > > work for PG16, or we do the rebase only once in the PG16 PR.
> > > >
> > > > Yesterday I had a brief private discussion with Max, my opinions (no
> > > > decision, just sharing):
> > > >
> > > >
> > > >    -
> > > >
> > > >    allowing a transition/review window (for example around 2–3 weeks),
> > > >    -
> > > >
> > > >    accelerating review and merge of the currently active PG14-based PRs
> > > >    during this period,
> > > >    -
> > > >
> > > >    and then temporarily locking the main branch and performing a final
> > > >    rebase/synchronization of the PG16 branch once - You don’t need to
> > > > repeatly
> > > >    rebase to catch up the main’s changes
> > > >
> > > > I think this could help:
> > > >
> > > >
> > > >    -
> > > >
> > > >    reduce repeated rebase work for the PG16 PR,
> > > >    -
> > > >
> > > >    give ecosystem components some reaction/adaptation time, help us
> > > >    coordinate with our next 2.x minor release,
> > > >    -
> > > >
> > > >    and help existing contributors land their in-flight work before the
> > > >    kernel transition fully happens.
> > > >
> > > > A good strategy will help us. Just sharing these thoughts for
> > discussion.
> > > > We can continue the discussion here, or an open meeting on this. Thanks
> > > > again for driving this huge effort forward.
> > > >
> > > > Best,
> > > > Dianjin Wang
> > > >
> > > > Jinbao Chen <ch...@gmail.com>于2026年5月26日 周二01:27写道：
> > > >
> > > > > Hi all,
> > > > > It has been three days since the PR was submitted. I intend to merge
> > it
> > > > > into the main branch today.
> > > > > Why I chose not to wait any longer:
> > > > > Firstly, we cannot allow the main trunk to be blocked for an extended
> > > > > period.
> > > > > Secondly, the sheer size of this PR makes a thorough and effective
> > review
> > > > > impossible.
> > > > >
> > > > > After merging, we will start fixing the FIXMEs. I am currently
> > sorting
> > > > them
> > > > > out and converting them
> > > > > into features in project https://github.com/orgs/apache/projects/497
> > > > >
> > > > > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <
> > reshkekirill@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org>
> > > > wrote:
> > > > > > >I think we should go ahead and merge it in.
> > > > > >
> > > > > > +1
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Kirill Reshke
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > > > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > For additional commands, e-mail: dev-help@cloudberry.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: dev-help@cloudberry.apache.org

Re: The pull request of merge postgres 15 and 16 is created

[Kirill Reshke <re...@gmail.com>]

Okay, so if I'm reading this correctly it's fine if I merge
https://github.com/apache/cloudberry/pull/1736 today, so we will be having
all viral fixes is current main.
I can also take an effort of merging this into to-be-main (pg16 merge)
branch, as well as other 16.10-16.14 CVE fixes.
Note that I'm speaking only about security fixes, which is about 50
commits, not whole 16.10-16.14 range

On Tue, 26 May 2026, 08:44 Dianjin Wang, <wa...@gmail.com> wrote:

> Hi all,
>
> Thanks everyone for the discussion.
>
> At this point, it seems the general consensus is leaning toward moving
> forward with merging the PG16 upgrade into the main branch soon. I
> respect and support the community consensus process here - disagree
> and commit, so let’s move forward together.
>
> That said, before the final merge operation happens, I still think it
> would be beneficial to leave a little more time (perhaps 1~2 more
> days) so contributors from other time zones also have a fair
> opportunity to participate in the discussion and review process.
>
> Also, in the parallel 2.2 release discussion thread started by Leonid,
> there was a suggestion to land key 2.2 features into the 2.x branch
> first. I personally support this direction. I think it addresses many
> of the concerns I mentioned earlier around transition coordination and
> ongoing in-flight work.
>
> With the 2.2 release work continuing for more time, I now agree that
> moving the PG16 kernel upgrade into the main branch sooner probably
> makes more sense overall.
>
> Before the merge happens, I think there are still several preparation
> steps that would help make the transition smoother (I’m happy to help
> with these tasks):
>
> * Create a copy branch from the current main branch (for example
> `PG14_ARCHIVE`) to mirror the existing PG14-based code line.
> * Apply a similar strategy to related ecosystem repositories where
> appropriate, including PXF and cloudberry-backup.
> * Clearly document the transition strategy for contributors, including
> which branches should receive PG14 fixes versus PG16-targeted
> development (can do after the PG16 merging).
>
> I think these steps can help reduce disruption during the transition
> period while still allowing us to move the PG16 work forward.
>
> Thanks again to everyone driving this huge effort.
>
>
> Best,
> Dianjin Wang
>
> On Tue, May 26, 2026 at 11:05 AM Jinbao Chen <ch...@gmail.com>
> wrote:
> >
> > When a new PR is merged into the main branch, the feature branch should,
> in
> > theory,
> > rebase onto the main branch. However, because this specific merge PR is
> > massive—containing
> > all the code for Postgres 15 and 16 along with numerous bug fixes—a
> rebase
> > has become
> > practically impossible. Consequently, the merge PR must instead merge the
> > main branch into
> > itself, which will create an additional merge commit on top of the
> Postgres
> > 16 merge. Eliminating
> > this redundant merge commit requires highly complex Git operations, which
> > takes time and introduces risk.
> >
> > Other PRs do not suffer from this issue. They can follow the standard
> > workflow and rebase normally,
> > which is much simpler and less risky than handling the merge PR.
> >
> > At the same time, if we choose to wait two to three weeks for existing
> PRs
> > to merge, new
> > PRs will inevitably keep coming in anyway. What, then, would be the point
> > of waiting?
> >
> > On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <wa...@gmail.com>
> wrote:
> >
> > > Hi Jinbao, all,
> > >
> > > First of all, I completely understand the concern about keeping the
> main
> > > branch blocked for too long, especially considering the size of this
> work
> > > and the complexity of continuously rebasing such a large upgrade
> branch. (I
> > > believe some PRs an be merged by now,  but still not somehow).
> > >
> > > However, I think this transition is not only about merging the
> PostgreSQL
> > > 16 kernel into the main repository itself, but also about preparing the
> > > broader Cloudberry ecosystem for the transition from PG14 to PG16.
> > >
> > > For example, several ecosystem components and CI pipelines are
> currently
> > > still tightly coupled with the existing main branch, including: PXF,
> > > cloudberry-backup and potentially other downstream components.
> > >
> > > Some time may be needed for contributors to evaluate how we can support
> > > both PG14 and PG16 during the transition period.
> > >
> > > Also, the past three days included the weekend, and according to normal
> > > Apache community practice, review windows around weekends are usually
> > > considered differently since many contributors may be offline or on
> > > vacation.
> > >
> > > Another concern is that we are also about to begin discussions around
> the
> > > 2.2 release (Leonid will send a discussion email later maybe), while
> at the
> > > same time there are still many active PRs currently under review on
> top of
> > > the PG14-based main branch — especially around Orca, PAX, Planner, and
> > > related areas. My concern is that once the main branch fully switches
> to
> > > the PG16 kernel, many of these existing PRs may will not be simply
> > > cherry-picked from the main to the 2.x release. I think it indeed
> needs a
> > > good balance to handle with this situation. Everyone handles the
> rebased
> > > work for PG16, or we do the rebase only once in the PG16 PR.
> > >
> > > Yesterday I had a brief private discussion with Max, my opinions (no
> > > decision, just sharing):
> > >
> > >
> > >    -
> > >
> > >    allowing a transition/review window (for example around 2–3 weeks),
> > >    -
> > >
> > >    accelerating review and merge of the currently active PG14-based PRs
> > >    during this period,
> > >    -
> > >
> > >    and then temporarily locking the main branch and performing a final
> > >    rebase/synchronization of the PG16 branch once - You don’t need to
> > > repeatly
> > >    rebase to catch up the main’s changes
> > >
> > > I think this could help:
> > >
> > >
> > >    -
> > >
> > >    reduce repeated rebase work for the PG16 PR,
> > >    -
> > >
> > >    give ecosystem components some reaction/adaptation time, help us
> > >    coordinate with our next 2.x minor release,
> > >    -
> > >
> > >    and help existing contributors land their in-flight work before the
> > >    kernel transition fully happens.
> > >
> > > A good strategy will help us. Just sharing these thoughts for
> discussion.
> > > We can continue the discussion here, or an open meeting on this. Thanks
> > > again for driving this huge effort forward.
> > >
> > > Best,
> > > Dianjin Wang
> > >
> > > Jinbao Chen <ch...@gmail.com>于2026年5月26日 周二01:27写道：
> > >
> > > > Hi all,
> > > > It has been three days since the PR was submitted. I intend to merge
> it
> > > > into the main branch today.
> > > > Why I chose not to wait any longer:
> > > > Firstly, we cannot allow the main trunk to be blocked for an extended
> > > > period.
> > > > Secondly, the sheer size of this PR makes a thorough and effective
> review
> > > > impossible.
> > > >
> > > > After merging, we will start fixing the FIXMEs. I am currently
> sorting
> > > them
> > > > out and converting them
> > > > into features in project https://github.com/orgs/apache/projects/497
> > > >
> > > > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <
> reshkekirill@gmail.com>
> > > > wrote:
> > > >
> > > > > On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org>
> > > wrote:
> > > > > >I think we should go ahead and merge it in.
> > > > >
> > > > > +1
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Kirill Reshke
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> For additional commands, e-mail: dev-help@cloudberry.apache.org
>
>

Re: The pull request of merge postgres 15 and 16 is created

[Dianjin Wang <wa...@gmail.com>]

Hi all,

Thanks everyone for the discussion.

At this point, it seems the general consensus is leaning toward moving
forward with merging the PG16 upgrade into the main branch soon. I
respect and support the community consensus process here - disagree
and commit, so let’s move forward together.

That said, before the final merge operation happens, I still think it
would be beneficial to leave a little more time (perhaps 1~2 more
days) so contributors from other time zones also have a fair
opportunity to participate in the discussion and review process.

Also, in the parallel 2.2 release discussion thread started by Leonid,
there was a suggestion to land key 2.2 features into the 2.x branch
first. I personally support this direction. I think it addresses many
of the concerns I mentioned earlier around transition coordination and
ongoing in-flight work.

With the 2.2 release work continuing for more time, I now agree that
moving the PG16 kernel upgrade into the main branch sooner probably
makes more sense overall.

Before the merge happens, I think there are still several preparation
steps that would help make the transition smoother (I’m happy to help
with these tasks):

* Create a copy branch from the current main branch (for example
`PG14_ARCHIVE`) to mirror the existing PG14-based code line.
* Apply a similar strategy to related ecosystem repositories where
appropriate, including PXF and cloudberry-backup.
* Clearly document the transition strategy for contributors, including
which branches should receive PG14 fixes versus PG16-targeted
development (can do after the PG16 merging).

I think these steps can help reduce disruption during the transition
period while still allowing us to move the PG16 work forward.

Thanks again to everyone driving this huge effort.


Best,
Dianjin Wang

On Tue, May 26, 2026 at 11:05 AM Jinbao Chen <ch...@gmail.com> wrote:
>
> When a new PR is merged into the main branch, the feature branch should, in
> theory,
> rebase onto the main branch. However, because this specific merge PR is
> massive—containing
> all the code for Postgres 15 and 16 along with numerous bug fixes—a rebase
> has become
> practically impossible. Consequently, the merge PR must instead merge the
> main branch into
> itself, which will create an additional merge commit on top of the Postgres
> 16 merge. Eliminating
> this redundant merge commit requires highly complex Git operations, which
> takes time and introduces risk.
>
> Other PRs do not suffer from this issue. They can follow the standard
> workflow and rebase normally,
> which is much simpler and less risky than handling the merge PR.
>
> At the same time, if we choose to wait two to three weeks for existing PRs
> to merge, new
> PRs will inevitably keep coming in anyway. What, then, would be the point
> of waiting?
>
> On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <wa...@gmail.com> wrote:
>
> > Hi Jinbao, all,
> >
> > First of all, I completely understand the concern about keeping the main
> > branch blocked for too long, especially considering the size of this work
> > and the complexity of continuously rebasing such a large upgrade branch. (I
> > believe some PRs an be merged by now,  but still not somehow).
> >
> > However, I think this transition is not only about merging the PostgreSQL
> > 16 kernel into the main repository itself, but also about preparing the
> > broader Cloudberry ecosystem for the transition from PG14 to PG16.
> >
> > For example, several ecosystem components and CI pipelines are currently
> > still tightly coupled with the existing main branch, including: PXF,
> > cloudberry-backup and potentially other downstream components.
> >
> > Some time may be needed for contributors to evaluate how we can support
> > both PG14 and PG16 during the transition period.
> >
> > Also, the past three days included the weekend, and according to normal
> > Apache community practice, review windows around weekends are usually
> > considered differently since many contributors may be offline or on
> > vacation.
> >
> > Another concern is that we are also about to begin discussions around the
> > 2.2 release (Leonid will send a discussion email later maybe), while at the
> > same time there are still many active PRs currently under review on top of
> > the PG14-based main branch — especially around Orca, PAX, Planner, and
> > related areas. My concern is that once the main branch fully switches to
> > the PG16 kernel, many of these existing PRs may will not be simply
> > cherry-picked from the main to the 2.x release. I think it indeed needs a
> > good balance to handle with this situation. Everyone handles the rebased
> > work for PG16, or we do the rebase only once in the PG16 PR.
> >
> > Yesterday I had a brief private discussion with Max, my opinions (no
> > decision, just sharing):
> >
> >
> >    -
> >
> >    allowing a transition/review window (for example around 2–3 weeks),
> >    -
> >
> >    accelerating review and merge of the currently active PG14-based PRs
> >    during this period,
> >    -
> >
> >    and then temporarily locking the main branch and performing a final
> >    rebase/synchronization of the PG16 branch once - You don’t need to
> > repeatly
> >    rebase to catch up the main’s changes
> >
> > I think this could help:
> >
> >
> >    -
> >
> >    reduce repeated rebase work for the PG16 PR,
> >    -
> >
> >    give ecosystem components some reaction/adaptation time, help us
> >    coordinate with our next 2.x minor release,
> >    -
> >
> >    and help existing contributors land their in-flight work before the
> >    kernel transition fully happens.
> >
> > A good strategy will help us. Just sharing these thoughts for discussion.
> > We can continue the discussion here, or an open meeting on this. Thanks
> > again for driving this huge effort forward.
> >
> > Best,
> > Dianjin Wang
> >
> > Jinbao Chen <ch...@gmail.com>于2026年5月26日 周二01:27写道：
> >
> > > Hi all,
> > > It has been three days since the PR was submitted. I intend to merge it
> > > into the main branch today.
> > > Why I chose not to wait any longer:
> > > Firstly, we cannot allow the main trunk to be blocked for an extended
> > > period.
> > > Secondly, the sheer size of this PR makes a thorough and effective review
> > > impossible.
> > >
> > > After merging, we will start fixing the FIXMEs. I am currently sorting
> > them
> > > out and converting them
> > > into features in project https://github.com/orgs/apache/projects/497
> > >
> > > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <re...@gmail.com>
> > > wrote:
> > >
> > > > On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org>
> > wrote:
> > > > >I think we should go ahead and merge it in.
> > > >
> > > > +1
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Kirill Reshke
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > > >
> > > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: dev-help@cloudberry.apache.org

Re: The pull request of merge postgres 15 and 16 is created

[Jinbao Chen <ch...@gmail.com>]

When a new PR is merged into the main branch, the feature branch should, in
theory,
rebase onto the main branch. However, because this specific merge PR is
massive—containing
all the code for Postgres 15 and 16 along with numerous bug fixes—a rebase
has become
practically impossible. Consequently, the merge PR must instead merge the
main branch into
itself, which will create an additional merge commit on top of the Postgres
16 merge. Eliminating
this redundant merge commit requires highly complex Git operations, which
takes time and introduces risk.

Other PRs do not suffer from this issue. They can follow the standard
workflow and rebase normally,
which is much simpler and less risky than handling the merge PR.

At the same time, if we choose to wait two to three weeks for existing PRs
to merge, new
PRs will inevitably keep coming in anyway. What, then, would be the point
of waiting?

On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <wa...@gmail.com> wrote:

> Hi Jinbao, all,
>
> First of all, I completely understand the concern about keeping the main
> branch blocked for too long, especially considering the size of this work
> and the complexity of continuously rebasing such a large upgrade branch. (I
> believe some PRs an be merged by now,  but still not somehow).
>
> However, I think this transition is not only about merging the PostgreSQL
> 16 kernel into the main repository itself, but also about preparing the
> broader Cloudberry ecosystem for the transition from PG14 to PG16.
>
> For example, several ecosystem components and CI pipelines are currently
> still tightly coupled with the existing main branch, including: PXF,
> cloudberry-backup and potentially other downstream components.
>
> Some time may be needed for contributors to evaluate how we can support
> both PG14 and PG16 during the transition period.
>
> Also, the past three days included the weekend, and according to normal
> Apache community practice, review windows around weekends are usually
> considered differently since many contributors may be offline or on
> vacation.
>
> Another concern is that we are also about to begin discussions around the
> 2.2 release (Leonid will send a discussion email later maybe), while at the
> same time there are still many active PRs currently under review on top of
> the PG14-based main branch — especially around Orca, PAX, Planner, and
> related areas. My concern is that once the main branch fully switches to
> the PG16 kernel, many of these existing PRs may will not be simply
> cherry-picked from the main to the 2.x release. I think it indeed needs a
> good balance to handle with this situation. Everyone handles the rebased
> work for PG16, or we do the rebase only once in the PG16 PR.
>
> Yesterday I had a brief private discussion with Max, my opinions (no
> decision, just sharing):
>
>
>    -
>
>    allowing a transition/review window (for example around 2–3 weeks),
>    -
>
>    accelerating review and merge of the currently active PG14-based PRs
>    during this period,
>    -
>
>    and then temporarily locking the main branch and performing a final
>    rebase/synchronization of the PG16 branch once - You don’t need to
> repeatly
>    rebase to catch up the main’s changes
>
> I think this could help:
>
>
>    -
>
>    reduce repeated rebase work for the PG16 PR,
>    -
>
>    give ecosystem components some reaction/adaptation time, help us
>    coordinate with our next 2.x minor release,
>    -
>
>    and help existing contributors land their in-flight work before the
>    kernel transition fully happens.
>
> A good strategy will help us. Just sharing these thoughts for discussion.
> We can continue the discussion here, or an open meeting on this. Thanks
> again for driving this huge effort forward.
>
> Best,
> Dianjin Wang
>
> Jinbao Chen <ch...@gmail.com>于2026年5月26日 周二01:27写道：
>
> > Hi all,
> > It has been three days since the PR was submitted. I intend to merge it
> > into the main branch today.
> > Why I chose not to wait any longer:
> > Firstly, we cannot allow the main trunk to be blocked for an extended
> > period.
> > Secondly, the sheer size of this PR makes a thorough and effective review
> > impossible.
> >
> > After merging, we will start fixing the FIXMEs. I am currently sorting
> them
> > out and converting them
> > into features in project https://github.com/orgs/apache/projects/497
> >
> > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <re...@gmail.com>
> > wrote:
> >
> > > On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org>
> wrote:
> > > >I think we should go ahead and merge it in.
> > >
> > > +1
> > >
> > >
> > > --
> > > Best regards,
> > > Kirill Reshke
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > > For additional commands, e-mail: dev-help@cloudberry.apache.org
> > >
> > >
> >
>

Re: The pull request of merge postgres 15 and 16 is created

[Dianjin Wang <wa...@gmail.com>]

Hi Jinbao, all,

First of all, I completely understand the concern about keeping the main
branch blocked for too long, especially considering the size of this work
and the complexity of continuously rebasing such a large upgrade branch. (I
believe some PRs an be merged by now,  but still not somehow).

However, I think this transition is not only about merging the PostgreSQL
16 kernel into the main repository itself, but also about preparing the
broader Cloudberry ecosystem for the transition from PG14 to PG16.

For example, several ecosystem components and CI pipelines are currently
still tightly coupled with the existing main branch, including: PXF,
cloudberry-backup and potentially other downstream components.

Some time may be needed for contributors to evaluate how we can support
both PG14 and PG16 during the transition period.

Also, the past three days included the weekend, and according to normal
Apache community practice, review windows around weekends are usually
considered differently since many contributors may be offline or on
vacation.

Another concern is that we are also about to begin discussions around the
2.2 release (Leonid will send a discussion email later maybe), while at the
same time there are still many active PRs currently under review on top of
the PG14-based main branch — especially around Orca, PAX, Planner, and
related areas. My concern is that once the main branch fully switches to
the PG16 kernel, many of these existing PRs may will not be simply
cherry-picked from the main to the 2.x release. I think it indeed needs a
good balance to handle with this situation. Everyone handles the rebased
work for PG16, or we do the rebase only once in the PG16 PR.

Yesterday I had a brief private discussion with Max, my opinions (no
decision, just sharing):


   -

   allowing a transition/review window (for example around 2–3 weeks),
   -

   accelerating review and merge of the currently active PG14-based PRs
   during this period,
   -

   and then temporarily locking the main branch and performing a final
   rebase/synchronization of the PG16 branch once - You don’t need to repeatly
   rebase to catch up the main’s changes

I think this could help:


   -

   reduce repeated rebase work for the PG16 PR,
   -

   give ecosystem components some reaction/adaptation time, help us
   coordinate with our next 2.x minor release,
   -

   and help existing contributors land their in-flight work before the
   kernel transition fully happens.

A good strategy will help us. Just sharing these thoughts for discussion.
We can continue the discussion here, or an open meeting on this. Thanks
again for driving this huge effort forward.

Best,
Dianjin Wang

Jinbao Chen <ch...@gmail.com>于2026年5月26日 周二01:27写道：

> Hi all,
> It has been three days since the PR was submitted. I intend to merge it
> into the main branch today.
> Why I chose not to wait any longer:
> Firstly, we cannot allow the main trunk to be blocked for an extended
> period.
> Secondly, the sheer size of this PR makes a thorough and effective review
> impossible.
>
> After merging, we will start fixing the FIXMEs. I am currently sorting them
> out and converting them
> into features in project https://github.com/orgs/apache/projects/497
>
> On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <re...@gmail.com>
> wrote:
>
> > On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org> wrote:
> > >I think we should go ahead and merge it in.
> >
> > +1
> >
> >
> > --
> > Best regards,
> > Kirill Reshke
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > For additional commands, e-mail: dev-help@cloudberry.apache.org
> >
> >
>

Re: The pull request of merge postgres 15 and 16 is created

[Max Yang <ma...@gmail.com>]

+1, which makes sense to me.
After the merge, other unmerged PRs will need to be rebased on the new main
branch.

Best regards, Max Yang


On Tue, May 26, 2026 at 1:27 AM Jinbao Chen <ch...@gmail.com>
wrote:

> Hi all,
> It has been three days since the PR was submitted. I intend to merge it
> into the main branch today.
> Why I chose not to wait any longer:
> Firstly, we cannot allow the main trunk to be blocked for an extended
> period.
> Secondly, the sheer size of this PR makes a thorough and effective review
> impossible.
>
> After merging, we will start fixing the FIXMEs. I am currently sorting them
> out and converting them
> into features in project https://github.com/orgs/apache/projects/497
>
> On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <re...@gmail.com>
> wrote:
>
> > On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org> wrote:
> > >I think we should go ahead and merge it in.
> >
> > +1
> >
> >
> > --
> > Best regards,
> > Kirill Reshke
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> > For additional commands, e-mail: dev-help@cloudberry.apache.org
> >
> >
>

Re: The pull request of merge postgres 15 and 16 is created

[Jinbao Chen <ch...@gmail.com>]

Hi all,
It has been three days since the PR was submitted. I intend to merge it
into the main branch today.
Why I chose not to wait any longer:
Firstly, we cannot allow the main trunk to be blocked for an extended
period.
Secondly, the sheer size of this PR makes a thorough and effective review
impossible.

After merging, we will start fixing the FIXMEs. I am currently sorting them
out and converting them
into features in project https://github.com/orgs/apache/projects/497

On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <re...@gmail.com>
wrote:

> On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org> wrote:
> >I think we should go ahead and merge it in.
>
> +1
>
>
> --
> Best regards,
> Kirill Reshke
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
> For additional commands, e-mail: dev-help@cloudberry.apache.org
>
>

Re: The pull request of merge postgres 15 and 16 is created

[Kirill Reshke <re...@gmail.com>]

On Mon, 25 May 2026 at 08:44, Zhang Mingli <av...@apache.org> wrote:
>I think we should go ahead and merge it in.

+1


-- 
Best regards,
Kirill Reshke

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: dev-help@cloudberry.apache.org

Re: The pull request of merge postgres 15 and 16 is created

[Zhang Mingli <av...@apache.org>]

On 2026/05/22 20:30:06 Jinbao Chen wrote:
> Hi all,
> 
> I am very glad that we have finally completed the merge of Postgres 15 and
> 16, and everyone is more
> 
> than welcome to review it.Here are some of the new features:
> 
> Key features and changes, sorted by importance:
> 
>    1.
> 
>    MERGE command
>    -
> 
>       SQL-standard MERGE for INSERT/UPDATE/DELETE in a single statement.
>       -
> 
>       ruleutils decompilation, PlaceHolderVar support in actions
>       -
> 
>       Fixes for partitioned tables, cross-partition triggers, RLS,
>       -
> 
>       EvalPlanQual, self-modified tuples, pg_stat_statements
>       2.
> 
>    Logical replication enhancements
>    -
> 
>       Built-in support for prepared transactions (2PC)
>       -
> 
>       Enable two-phase via replication protocol
>       -
> 
>       Streaming changes after speculative aborts
>       -
> 
>       New pg_create_subscription predefined role
>       -
> 
>       Parallel apply workers (PG 16)
>       -
> 
>       Row/column filtering, schema-level publication (PG 15)
>       -
> 
>       Critical fix for data loss in logical replication
>       -
> 
>       Slot invalidation, snapshot, and memory leak fixes
>       3.
> 
>    SQL/JSON
>    -
> 
>       IS JSON predicate
>       -
> 
>       Standard JSON constructor functions (json_array, json_object,
>       json_scalar, json_serialize)
>       -
> 
>       Auto-generated query jumbling via gen_node_support.pl
>       -
> 
>       Fix json_array() subquery double transformation
>       4.
> 
>    WAL and storage subsystem
>    -
> 
>       LZ4 compression for full-page writes (FPW)
>       -
> 
>       Custom WAL resource managers
>       -
> 
>       Skip WAL recycling/preallocation during archive recovery
>       -
> 
>       XLOG_FPI_FOR_HINT honors full_page_writes setting
>       -
> 
>       Direct I/O support on macOS
>       -
> 
>       Buffer manager infrastructure refactor for faster relation extension
>       -
> 
>       New smgrzeroextend(), FileZero(), FileFallocate()
>       -
> 
>       Remove HeapBitmapScan skip_fetch optimization (correctness issue)
>       -
> 
>       WAL/Recovery separation: xlogrecovery.c, xlogprefetcher.c (PG 15)
>       -
> 
>       Backup sink architecture (PG 15)
>       5.
> 
>    Query optimizer / executor
>    Performance:
>    -
> 
>       Hash table acceleration for NOT IN(values)
>       -
> 
>       Datum sorts for single-column sorts
>       -
> 
>       Result Cache renamed to Memoize with ongoing fixes
>       -
> 
>       Parallel Hash Full Join
>       -
> 
>       Reduced planning cost for deeply-nested views
>       -
> 
>       Fewer pallocs when building partition bounds
>       -
> 
>       Outer join optimization enhancement (PG 16)
>       -
> 
>       Symmetric hash join optimization (PG 16)
>       Critical fixes:
>       -
> 
>       Planner failure to identify multiple hashable ScalarArrayOpExprs
>       -
> 
>       Consistent whole-row Var construction in parsing and planning
>       -
> 
>       WindowAgg evaluation crash
>       -
> 
>       WITH RECURSIVE UNION assert failure
>       -
> 
>       ORDER BY / DISTINCT aggregates with FILTER
>       -
> 
>       setrefs.c missing expression processing on prune steps
>       -
> 
>       Parallel Hash Join extreme skew detection
>       6.
> 
>    pgstat monitoring enhancements
>    pgstat shared memory rewrite (PG 15):
>    -
> 
>       Stats collector process removed; stats now in shared memory
>       -
> 
>       Monolithic pgstat.c split into 14 files under utils/activity/
>       pg_stat_io (PG 16 new view):
>       -
> 
>       Detailed I/O statistics: shared buffer hits, I/O times, writeback
>       pg_stat_statements:
>       -
> 
>       JIT counters, temp file block I/O timing
>       -
> 
>       Utility query string normalization, MERGE support
>       -
> 
>       32-bit integer overflow fix
>       Other:
>       -
> 
>       pg_stat_wal time accumulation as instr_time
>       -
> 
>       Macro-generated pg_stat_get*() functions for tables and databases
>       -
> 
>       Enhanced pg_stat_reset_single_table_counters
>       -
> 
>       SP-GiST index scans counted in pg_stat
>       -
> 
>       New test helpers: pg_stat_force_next_flush(), pg_stat_have_stats()
>       7.
> 
>    libpq and client protocol
>    -
> 
>       New PQsendFlushRequest
>       -
> 
>       Pipeline mode state machine fix
>       -
> 
>       SASL code refactored to generic interface
>       -
> 
>       Escape function fixes for invalid encoding data (security)
>       -
> 
>       PQescapeLiteral()/PQescapeIdentifier() length handling fix
>       -
> 
>       New pg_encoding_set_invalid()
>       -
> 
>       Build-time check that libpq doesn't call exit()/abort()
>       8.
> 
>    Security and privilege model
>    -
> 
>       CREATEROLE privilege restrictions (major security improvement)
>       -
> 
>       New GUCs: createrole_self_grant, reserved_connections
>       -
> 
>       New predefined roles: pg_maintain, pg_create_subscription
>       -
> 
>       Non-superuser predefined roles for vacuum/analyze
>       -
> 
>       Revoke PUBLIC CREATE from public schema (now owned by
>       pg_database_owner)
>       -
> 
>       Security invoker views (SECURITY INVOKER)
>       -
> 
>       session_authorization and role interaction fixes
>       -
> 
>       scram_SaltedPassword() integer overflow fix
>       9.
> 
>    pg_dump / pg_upgrade / pg_basebackup toolchain
>    pg_dump:
>    -
> 
>       Generic compression API, zstd support, LZ4 frame-only format
>       pg_basebackup:
>       -
> 
>       Extended compression options, server-side compression with -Fp
>       -
> 
>       Client-side LZ4 decompression, parallel zstd compression
>       pg_upgrade:
>       -
> 
>       Fix unintentional 'NULL' string literal
>       -
> 
>       Fix XMLSERIALIZE(NO INDENT) cross-version upgrade
>       -
> 
>       pg_dumpall handling of dangling OIDs in pg_auth_members
>       10.
> 
>    Partitioned table improvements
>    -
> 
>       Self-referencing FKs in partitioned tables
>       -
> 
>       Detach partition with top-level FK fix
>       -
> 
>       Reset relhassubclass on ATTACH
>       -
> 
>       Trigger rename consistency, preserve firing state on clone
>       -
> 
>       Disallow partitionwise join/grouping on collation mismatch
>       11.
> 
>    ICU and collation
>    -
> 
>       Build ICU support by default
>       -
> 
>       initdb uses uloc_getDefault()
>       -
> 
>       CREATE DATABASE LOCALE applies to all collation providers
>       12.
> 
>    Node support function auto-generation (FIXME)
>    -
> 
>       gen_node_support.pl auto-generates
>       copyfuncs/equalfuncs/outfuncs/readfuncs
>       -
> 
>       Query jumbling code auto-generation
>       -
> 
>       NodeTag ABI stability check
>       13.
> 
>    Global renames and structural changes
>    -
> 
>       RelFileNode -> RelFileLocator (pervasive rename across hundreds of
>       files)
>       -
> 
>       GUC system split: guc.c -> guc.c + guc_tables.c + guc_funcs.c
>       -
> 
>       varatt.h separated from postgres.h
>       -
> 
>       Test framework: PostgresNode.pm -> PostgreSQL::Test::Cluster
>       14.
> 
>    SQL types and functions
>    -
> 
>       Numeric scale allows negative or greater than precision
>       -
> 
>       New ANY_VALUE aggregate function
>       -
> 
>       unnest(multirange), range_agg with multirange inputs
>       -
> 
>       pg_size_pretty/pg_size_bytes support petabytes
>       -
> 
>       ALTER TABLE SET ACCESS METHOD
>       -
> 
>       SYSTEM_USER function
>       -
> 
>       numeric_mul() overflow fix
>       15.
> 
>    psql improvements
>    -
> 
>       PSQL_WATCH_PAGER for \watch command
>       -
> 
>       New \drg command for role grants
>       -
> 
>       \copy from sends data in larger chunks
>       -
> 
>       pg_waldump --rmgr multiple specification
>       16.
> 
>    Critical data corruption and crash fixes
>    -
> 
>       Fix data corruption when relation truncation fails
>       -
> 
>       Fail instead of corrupting page header on non-LP_NORMAL TID update
>       -
> 
>       Fix unsafe BufferDescriptors access
>       -
> 
>       GB18030 SIGSEGV from out-of-bounds read
>       -
> 
>       Snowball stemmer null pointer dereference after OOM
>       -
> 
>       Rare standby assertion failure on primary restart
>       -
> 
>       catcache invalidation during list entry construction
>       17.
> 
>    Vacuum / Autovacuum
>    -
> 
>       Parallel VACUUM (PG 16, vacuumparallel.c new file)
>       -
> 
>       ON COMMIT DELETE ROWS avoids ERROR after relhassubclass=f
>       -
> 
>       Use WaitLatch() instead of pg_usleep() at end-of-vacuum truncation
>       -
> 
>       Prevent numeric overflow in parallel numeric aggregates
>       -
> 
>       ANALYZE preserves relhasindex for partitioned tables
> 
> 
> Currently, there are still some features that are not fully functional yet.
> We have left some "FIXME" tags,
> 
> which will be fixed one after another in the coming weeks. We will create a
> feature for each "FIXME" in
> 
> the project board, and anyone is welcome to help fix them:
> https://github.com/orgs/apache/projects/497
> 
> 
> Since the amount of code in this merge is massive, handling conflicts will
> be very troublesome if new code
> 
> is merged into the main branch. Therefore, please temporarily pause merging
> any code for the next few days.
> 
> 
> Below is the list of contributors to this merge.
> 
> Jinbao Chen <ch...@gmail.com>
> 
> liushengsong <ls...@gmail.com>
> 
> reshke <re...@double.cloud>
> 
> Hao Wu <gf...@gmail.com>
> 
> Jianghua.yjh <yj...@gmail.com>
> 
> Dianjin Wang <wa...@gmail.com>

Thanks, 

Hi Jinbao and team,

Thanks for the tremendous effort on getting this merge done — this is a huge amount of work.

As with our previous version upgrades, a PR of this scope is simply impossible for any single person to review end-to-end. I think we should go ahead and merge it in. Apart from genuinely critical issues that need to be addressed upfront, all the smaller problems can be tracked and fixed incrementally afterwards — the FIXME items on the project board are exactly the right way to handle that.

Great work, everyone.

Zhang Mingli


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cloudberry.apache.org
For additional commands, e-mail: dev-help@cloudberry.apache.org