This is an automated email from the ASF dual-hosted git repository. reshke pushed a commit to branch cbdb-postgres-merge in repository https://gitbox.apache.org/repos/asf/cloudberry.git
commit 1fe329a730b3d7f56f7aee1cd3c005459e8b9eb5 Author: reshke <[email protected]> AuthorDate: Tue Dec 23 17:57:08 2025 +0000 resolve a few doc rebase markers --- doc/src/sgml/brin.sgml | 4 ---- doc/src/sgml/custom-rmgr.sgml | 4 ---- doc/src/sgml/hash.sgml | 8 -------- doc/src/sgml/indices.sgml | 4 ---- doc/src/sgml/limits.sgml | 4 ---- doc/src/sgml/ref/create_foreign_table.sgml | 4 ---- 6 files changed, 28 deletions(-) diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml index 815810f4ee7..9c5ffcddf84 100644 --- a/doc/src/sgml/brin.sgml +++ b/doc/src/sgml/brin.sgml @@ -75,11 +75,7 @@ summarized will cause the summary information to be updated with data from the new tuples. When a new page is created that does not fall within the last -<<<<<<< HEAD - summarized range, the range that the new page belongs into -======= summarized range, the range that the new page belongs to ->>>>>>> REL_16_9 does not automatically acquire a summary tuple; those tuples remain unsummarized until a summarization run is invoked later, creating the initial summary for that range. diff --git a/doc/src/sgml/custom-rmgr.sgml b/doc/src/sgml/custom-rmgr.sgml index ae04f48d396..905c1e7f26c 100644 --- a/doc/src/sgml/custom-rmgr.sgml +++ b/doc/src/sgml/custom-rmgr.sgml @@ -19,11 +19,7 @@ an extension to implement. </para> <para> -<<<<<<< HEAD - To create a new custom WAL resouce manager, first define an -======= To create a new custom WAL resource manager, first define an ->>>>>>> REL_16_9 <structname>RmgrData</structname> structure with implementations for the resource manager methods. Refer to <filename>src/backend/access/transam/README</filename> and diff --git a/doc/src/sgml/hash.sgml b/doc/src/sgml/hash.sgml index 0678f97012b..e35911ebf8e 100644 --- a/doc/src/sgml/hash.sgml +++ b/doc/src/sgml/hash.sgml @@ -49,11 +49,7 @@ contrast, a hash index allows accessing the bucket pages directly, thereby potentially reducing index access time in larger tables. This reduction in "logical I/O" becomes even more pronounced on indexes/data -<<<<<<< HEAD - larger than shared_buffers/RAM. -======= larger than shared_buffers/RAM. ->>>>>>> REL_16_9 </para> <para> @@ -93,11 +89,7 @@ overflow page becomes empty, overflow pages can be recycled for reuse in other buckets, though we never return them to the operating system. There is currently no provision to shrink a hash index, other than by -<<<<<<< HEAD - rebuilding it with REINDEX. -======= rebuilding it with REINDEX. ->>>>>>> REL_16_9 There is no provision for reducing the number of buckets, either. </para> diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml index 13c7d469205..a9bb0bfab5c 100644 --- a/doc/src/sgml/indices.sgml +++ b/doc/src/sgml/indices.sgml @@ -787,11 +787,7 @@ CREATE INDEX people_names ON people ((first_name || ' ' || last_name)); <para> Index expressions are relatively expensive to maintain, because the derived expression(s) must be computed for each row insertion -<<<<<<< HEAD - and non-HOT update. However, the index expressions are -======= and <link linkend="storage-hot">non-HOT update.</link> However, the index expressions are ->>>>>>> REL_16_9 <emphasis>not</emphasis> recomputed during an indexed search, since they are already stored in the index. In both examples above, the system sees the query as just <literal>WHERE indexedcolumn = 'constant'</literal> diff --git a/doc/src/sgml/limits.sgml b/doc/src/sgml/limits.sgml index bec0dc09b4c..f26f4466719 100644 --- a/doc/src/sgml/limits.sgml +++ b/doc/src/sgml/limits.sgml @@ -64,11 +64,7 @@ <row> <entry>columns in a result set</entry> -<<<<<<< HEAD - <entry>1664</entry> -======= <entry>1,664</entry> ->>>>>>> REL_16_9 <entry></entry> </row> diff --git a/doc/src/sgml/ref/create_foreign_table.sgml b/doc/src/sgml/ref/create_foreign_table.sgml index 6e7e4710478..6552cee2896 100644 --- a/doc/src/sgml/ref/create_foreign_table.sgml +++ b/doc/src/sgml/ref/create_foreign_table.sgml @@ -423,11 +423,7 @@ int totalNumberOfSegments = getgpsegmentCount(); an <command>UPDATE</command> that changes the partition key value can cause a row to be moved from a local partition to a foreign-table partition, provided the foreign data wrapper supports tuple routing. -<<<<<<< HEAD - However it is not currently possible to move a row from a -======= However, it is not currently possible to move a row from a ->>>>>>> REL_16_9 foreign-table partition to another partition. An <command>UPDATE</command> that would require doing that will fail due to the partitioning constraint, assuming that that is properly --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
