Repository navigation
Fix: license rewriting - #5
Merged
Merged
Conversation
Modify `Cloudberry Inc` to `Greenplum Inc`
tuhaihe
requested review from
my-ship-it and
tuhaihe
and removed request for
my-ship-it and
tuhaihe
June 20, 2023 02:04
my-ship-it
approved these changes
Jun 25, 2023
HuSen8891
added a commit
to HuSen8891/cloudberrydb
that referenced
this pull request
Mar 1, 2024
For test case:
create table t0(c0 inet) distributed randomly;
create table t2(c0 inet) distributed randomly;
create table t3(c0 inet) distributed randomly;
SELECT ALL t2.c0, t3.c0, t0.c0 FROM t0, ONLY t3 FULL OUTER JOIN t2 ON ((t2.c0)=(t3.c0))
WHERE (((('0.5496844753539182')||(t3.c0)))LIKE(CAST((0.13292931)::MONEY AS VARCHAR(971))))
UNION ALL SELECT t2.c0, t3.c0, t0.c0 FROM t0, ONLY t3 FULL OUTER JOIN t2 ON ((t2.c0)=(t3.c0))
WHERE NOT ((((('0.5496844753539182')||(t3.c0)))LIKE((CAST(0.13292931 AS MONEY))::VARCHAR(971))))
UNION ALL SELECT ALL t2.c0, t3.c0, t0.c0 FROM t0*, ONLY t3 FULL OUTER JOIN t2 ON ((t2.c0)=(t3.c0))
WHERE ((((('0.5496844753539182')||(t3.c0)))LIKE((CAST(0.13292931 AS MONEY))::VARCHAR(971)))) ISNULL;
will cause crash because of assert failure in 'create_plan_recurse'.
'apache#3 0x00007fe94eccf476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
apache#4 0x00007fe94ecb57f3 in __GI_abort () at ./stdlib/abort.c:79
apache#5 0x00007fe94fcdd548 in ExceptionalCondition (conditionName=0x7fe95043dcd0 "best_path->parallel_workers == best_path->locus.parallel_workers",
errorType=0x7fe95043db06 "FailedAssertion", fileName=0x7fe95043dbdb "createplan.c", lineNumber=623) at assert.c:48
apache#6 0x00007fe94f94918f in create_plan_recurse (root=0x55d7cbe96f78, best_path=0x55d7cbec0380, flags=1) at createplan.c:623
apache#7 0x00007fe94f94a1f8 in create_append_plan (root=0x55d7cbe96f78, best_path=0x55d7cbec0700, flags=1) at createplan.c:1380
apache#8 0x00007fe94f948d37 in create_plan_recurse (root=0x55d7cbe96f78, best_path=0x55d7cbec0700, flags=1) at createplan.c:481
apache#9 0x00007fe94f94e2d1 in create_motion_plan (root=0x55d7cbe96f78, path=0x55d7cbec0e50) at createplan.c:3316
#10 0x00007fe94f9490dc in create_plan_recurse (root=0x55d7cbe96f78, best_path=0x55d7cbec0e50, flags=1) at createplan.c:608
apache#11 0x00007fe94f948ba3 in create_plan (root=0x55d7cbe96f78, best_path=0x55d7cbec0e50, curSlice=0x55d7cbe96f20) at createplan.c:392'
The parallel_workers should be set to zero because parallel full join is not supported yet.
my-ship-it
pushed a commit
that referenced
this pull request
Mar 4, 2024
For test case:
create table t0(c0 inet) distributed randomly;
create table t2(c0 inet) distributed randomly;
create table t3(c0 inet) distributed randomly;
SELECT ALL t2.c0, t3.c0, t0.c0 FROM t0, ONLY t3 FULL OUTER JOIN t2 ON ((t2.c0)=(t3.c0))
WHERE (((('0.5496844753539182')||(t3.c0)))LIKE(CAST((0.13292931)::MONEY AS VARCHAR(971))))
UNION ALL SELECT t2.c0, t3.c0, t0.c0 FROM t0, ONLY t3 FULL OUTER JOIN t2 ON ((t2.c0)=(t3.c0))
WHERE NOT ((((('0.5496844753539182')||(t3.c0)))LIKE((CAST(0.13292931 AS MONEY))::VARCHAR(971))))
UNION ALL SELECT ALL t2.c0, t3.c0, t0.c0 FROM t0*, ONLY t3 FULL OUTER JOIN t2 ON ((t2.c0)=(t3.c0))
WHERE ((((('0.5496844753539182')||(t3.c0)))LIKE((CAST(0.13292931 AS MONEY))::VARCHAR(971)))) ISNULL;
will cause crash because of assert failure in 'create_plan_recurse'.
'#3 0x00007fe94eccf476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007fe94ecb57f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007fe94fcdd548 in ExceptionalCondition (conditionName=0x7fe95043dcd0 "best_path->parallel_workers == best_path->locus.parallel_workers",
errorType=0x7fe95043db06 "FailedAssertion", fileName=0x7fe95043dbdb "createplan.c", lineNumber=623) at assert.c:48
#6 0x00007fe94f94918f in create_plan_recurse (root=0x55d7cbe96f78, best_path=0x55d7cbec0380, flags=1) at createplan.c:623
#7 0x00007fe94f94a1f8 in create_append_plan (root=0x55d7cbe96f78, best_path=0x55d7cbec0700, flags=1) at createplan.c:1380
#8 0x00007fe94f948d37 in create_plan_recurse (root=0x55d7cbe96f78, best_path=0x55d7cbec0700, flags=1) at createplan.c:481
#9 0x00007fe94f94e2d1 in create_motion_plan (root=0x55d7cbe96f78, path=0x55d7cbec0e50) at createplan.c:3316
#10 0x00007fe94f9490dc in create_plan_recurse (root=0x55d7cbe96f78, best_path=0x55d7cbec0e50, flags=1) at createplan.c:608
#11 0x00007fe94f948ba3 in create_plan (root=0x55d7cbe96f78, best_path=0x55d7cbec0e50, curSlice=0x55d7cbe96f20) at createplan.c:392'
The parallel_workers should be set to zero because parallel full join is not supported yet.
foreyes
pushed a commit
to foreyes/cloudberrydb
that referenced
this pull request
Jul 8, 2024
For test case:
create table t0(c0 inet) distributed randomly;
create table t2(c0 inet) distributed randomly;
create table t3(c0 inet) distributed randomly;
SELECT ALL t2.c0, t3.c0, t0.c0 FROM t0, ONLY t3 FULL OUTER JOIN t2 ON ((t2.c0)=(t3.c0))
WHERE (((('0.5496844753539182')||(t3.c0)))LIKE(CAST((0.13292931)::MONEY AS VARCHAR(971))))
UNION ALL SELECT t2.c0, t3.c0, t0.c0 FROM t0, ONLY t3 FULL OUTER JOIN t2 ON ((t2.c0)=(t3.c0))
WHERE NOT ((((('0.5496844753539182')||(t3.c0)))LIKE((CAST(0.13292931 AS MONEY))::VARCHAR(971))))
UNION ALL SELECT ALL t2.c0, t3.c0, t0.c0 FROM t0*, ONLY t3 FULL OUTER JOIN t2 ON ((t2.c0)=(t3.c0))
WHERE ((((('0.5496844753539182')||(t3.c0)))LIKE((CAST(0.13292931 AS MONEY))::VARCHAR(971)))) ISNULL;
will cause crash because of assert failure in 'create_plan_recurse'.
'apache#3 0x00007fe94eccf476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
apache#4 0x00007fe94ecb57f3 in __GI_abort () at ./stdlib/abort.c:79
apache#5 0x00007fe94fcdd548 in ExceptionalCondition (conditionName=0x7fe95043dcd0 "best_path->parallel_workers == best_path->locus.parallel_workers",
errorType=0x7fe95043db06 "FailedAssertion", fileName=0x7fe95043dbdb "createplan.c", lineNumber=623) at assert.c:48
apache#6 0x00007fe94f94918f in create_plan_recurse (root=0x55d7cbe96f78, best_path=0x55d7cbec0380, flags=1) at createplan.c:623
apache#7 0x00007fe94f94a1f8 in create_append_plan (root=0x55d7cbe96f78, best_path=0x55d7cbec0700, flags=1) at createplan.c:1380
apache#8 0x00007fe94f948d37 in create_plan_recurse (root=0x55d7cbe96f78, best_path=0x55d7cbec0700, flags=1) at createplan.c:481
apache#9 0x00007fe94f94e2d1 in create_motion_plan (root=0x55d7cbe96f78, path=0x55d7cbec0e50) at createplan.c:3316
#10 0x00007fe94f9490dc in create_plan_recurse (root=0x55d7cbe96f78, best_path=0x55d7cbec0e50, flags=1) at createplan.c:608
apache#11 0x00007fe94f948ba3 in create_plan (root=0x55d7cbe96f78, best_path=0x55d7cbec0e50, curSlice=0x55d7cbe96f20) at createplan.c:392'
The parallel_workers should be set to zero because parallel full join is not supported yet.
avamingli
pushed a commit
that referenced
this pull request
Jan 23, 2025
## Problem
An error occurs in python lib when a plpython function is executed.
After our analysis, in the user's cluster, a plpython UDF
was running with the unstable network, and got a timeout error:
`failed to acquire resources on one or more segments`.
Then a plpython UDF was run in the same session, and the UDF
failed with GC error.
Here is the core dump:
```
2023-11-24 10:15:18.945507 CST,,,p2705198,th2081832064,,,,0,,,seg-1,,,,,"LOG","00000","3rd party error log:
#0 0x7f7c68b6d55b in frame_dealloc /home/cc/repo/cpython/Objects/frameobject.c:509:5
#1 0x7f7c68b5109d in gen_send_ex /home/cc/repo/cpython/Objects/genobject.c:108:9
#2 0x7f7c68af9ddd in PyIter_Next /home/cc/repo/cpython/Objects/abstract.c:3118:14
#3 0x7f7c78caa5c0 in PLy_exec_function /home/cc/repo/gpdb6/src/pl/plpython/plpy_exec.c:134:11
#4 0x7f7c78cb5ffb in plpython_call_handler /home/cc/repo/gpdb6/src/pl/plpython/plpy_main.c:387:13
#5 0x562f5e008bb5 in ExecMakeTableFunctionResult /home/cc/repo/gpdb6/src/backend/executor/execQual.c:2395:13
#6 0x562f5e0dddec in FunctionNext_guts /home/cc/repo/gpdb6/src/backend/executor/nodeFunctionscan.c:142:5
#7 0x562f5e0da094 in FunctionNext /home/cc/repo/gpdb6/src/backend/executor/nodeFunctionscan.c:350:11
#8 0x562f5e03d4b0 in ExecScanFetch /home/cc/repo/gpdb6/src/backend/executor/execScan.c:84:9
#9 0x562f5e03cd8f in ExecScan /home/cc/repo/gpdb6/src/backend/executor/execScan.c:154:10
#10 0x562f5e0da072 in ExecFunctionScan /home/cc/repo/gpdb6/src/backend/executor/nodeFunctionscan.c:380:9
#11 0x562f5e001a1c in ExecProcNode /home/cc/repo/gpdb6/src/backend/executor/execProcnode.c:1071:13
#12 0x562f5dfe6377 in ExecutePlan /home/cc/repo/gpdb6/src/backend/executor/execMain.c:3202:10
#13 0x562f5dfe5bf4 in standard_ExecutorRun /home/cc/repo/gpdb6/src/backend/executor/execMain.c:1171:5
#14 0x562f5dfe4877 in ExecutorRun /home/cc/repo/gpdb6/src/backend/executor/execMain.c:992:4
#15 0x562f5e857e69 in PortalRunSelect /home/cc/repo/gpdb6/src/backend/tcop/pquery.c:1164:4
#16 0x562f5e856d3f in PortalRun /home/cc/repo/gpdb6/src/backend/tcop/pquery.c:1005:18
#17 0x562f5e84607a in exec_simple_query /home/cc/repo/gpdb6/src/backend/tcop/postgres.c:1848:10
```
## Reproduce
We can use a simple procedure to reproduce the above problem:
- set timeout GUC: `gpconfig -c gp_segment_connect_timeout -v 5` and `gpstop -ari`
- prepare function:
```
CREATE EXTENSION plpythonu;
CREATE OR REPLACE FUNCTION test_func() RETURNS SETOF int AS
$$
plpy.execute("select pg_backend_pid()")
for i in range(0, 5):
yield (i)
$$ LANGUAGE plpythonu;
```
- exit from the current psql session.
- stop the postmaster of segment: `gdb -p "the pid of segment postmaster"`
- enter a psql session.
- call `SELECT test_func();` and get error
```
gpadmin=# select test_func();
ERROR: function "test_func" error fetching next item from iterator (plpy_elog.c:121)
DETAIL: Exception: failed to acquire resources on one or more segments
CONTEXT: Traceback (most recent call last):
PL/Python function "test_func"
```
- quit gdb and make postmaster runnable.
- call `SELECT test_func();` again and get panic
```
gpadmin=# SELECT test_func();
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
```
## Analysis
- There is an SPI call in test_func(): `plpy.execute()`.
- Then coordinator will start a subtransaction by PLy_spi_subtransaction_begin();
- Meanwhile, if the segment cannot receive the instruction from the coordinator,
the subtransaction beginning procedure return fails.
- BUT! The Python processor does not know whether an error happened and
does not clean its environment.
- Then the next plpython UDF in the same session will fail due to the wrong
Python environment.
## Solution
- Use try-catch to catch the exception caused by PLy_spi_subtransaction_begin()
- set the python error indicator by PLy_spi_exception_set()
Co-authored-by: Chen Mulong <chenmulong@gmail.com>
12 tasks
Vlasdislav
pushed a commit
to Vlasdislav/cloudberry
that referenced
this pull request
Jun 23, 2026
This commit introduces new mdb internal role mdb_superuser. Role is capaple of: GRANT/REVOKE any set of priviledges to/from any object in database. Has power of pg_database_owner in any database, including: DROP any object in database (except system catalog and stuff) Role is NOT capaple of: Create database, role, extension or alter other roles with such priviledges. Transfer ownership to /pass has_priv of roles: PG_READ_ALL_DATA PG_WRITE_ALL_DATA PG_EXECUTE_SERVER_PROGRAM PG_READ_SERVER_FILES PG_WRITE_SERVER_FILES PG_DATABASE_OWNER Fix configure.ac USE_MDBLOCALES option handling Apply autoreconf stuff Set missing ok parameter ito true while acquiring mdb_superuser oid In regress tests, nobody creates mdb_superuser role, so missing ok is fine Allow mdb_superuser to have power of pg_database_owner Allow mdb_superuser to alter objects and grant ACl to objects, owner by pg_database_owner. Also, when acl check, allow mdb_supersuer use pg_database_owner role power to pass check
5 of 13 tasks
1 of 2 tasks
13 tasks
yjhjstz
pushed a commit
to yjhjstz/cloudberry
that referenced
this pull request
Oct 27, 2026
(cherry picked from commit a48a9410123ebe3481ebfe66bef8f4bf4af14fff) aocs_writecol_finish() calls AppendOnlyBlockDirectory_End_writeCols() whenever the relation has a block directory, on the assumption that Init_writeCols() must have run. It need not have: aocs_writecol_rewrite() enters its loop on nseg >= 1 but skips every segfile whose total_tupcount is 0, so with a table that has segfiles but no live tuples, aocs_writecol_newsegfiles() -- and with it Init_writeCols() -- is never reached. palloc0 the descriptor and check blkdirRel before ending. This one does crash cbdb today. Reproducer: CREATE TABLE t(a int, b int) USING ao_column DISTRIBUTED BY (a); CREATE INDEX t_i ON t(a); -- makes blkdirrelid valid INSERT INTO t SELECT i,i FROM generate_series(1,10) i; DELETE FROM t; VACUUM t; -- segfiles remain, all empty ALTER TABLE t ALTER COLUMN b TYPE bigint; takes down the QE. Core confirms the cause exactly: apache#5 AppendOnlyBlockDirectory_End_writeCols (appendonlyblockdirectory.c:1793) apache#6 aocs_writecol_finish (aocsam.c:2907) apache#7 aocs_writecol_rewrite (aocsam.c:3954) (gdb) p desc->blockDirectory.blkdirRel $1 = (Relation) 0x7f7f7f7f7f7f7f7f i.e. never initialised, still holding palloc's fill pattern. Upstream says "the bug is covered by tests in subsequent commit", but that commit is not ported yet, so the reproducer is added to aoco_column_rewrite now rather than leaving the fix untested. Verified it has teeth by reverting the two lines and rerunning: the test fails with the QE connection dropping at the ALTER. Verified: AO/AOCS regression 24/24, AO isolation2 136/136 plus ao_partial_scan. uao/max_concurrency2_row failed in two of five full runs today and passed 3/3 standalone. It cannot be this commit: aocs_writecol_init() and aocs_writecol_finish() are reachable only through the AOCO table AM slots (aoco_relation_add_columns / aoco_relation_rewrite_columns), and that test uses ao_row. Both failures were in its "VACUUM in the presence of an old snapshot" section, which asserts exactly which segfiles got compacted versus left in AWAITING_DROP -- and the test opens 128 sessions and closes none of them, so the xmin horizon it vacuums against depends on how promptly 127 idle sessions' segment backends settle. Same family as the uao/brin_column and ao_partial_scan flakes already recorded.
yjhjstz
pushed a commit
to yjhjstz/cloudberry
that referenced
this pull request
Oct 27, 2026
(cherry picked from commit a48a9410123ebe3481ebfe66bef8f4bf4af14fff) aocs_writecol_finish() calls AppendOnlyBlockDirectory_End_writeCols() whenever the relation has a block directory, on the assumption that Init_writeCols() must have run. It need not have: aocs_writecol_rewrite() enters its loop on nseg >= 1 but skips every segfile whose total_tupcount is 0, so with a table that has segfiles but no live tuples, aocs_writecol_newsegfiles() -- and with it Init_writeCols() -- is never reached. palloc0 the descriptor and check blkdirRel before ending. This one does crash cbdb today. Reproducer: CREATE TABLE t(a int, b int) USING ao_column DISTRIBUTED BY (a); CREATE INDEX t_i ON t(a); -- makes blkdirrelid valid INSERT INTO t SELECT i,i FROM generate_series(1,10) i; DELETE FROM t; VACUUM t; -- segfiles remain, all empty ALTER TABLE t ALTER COLUMN b TYPE bigint; takes down the QE. Core confirms the cause exactly: apache#5 AppendOnlyBlockDirectory_End_writeCols (appendonlyblockdirectory.c:1793) apache#6 aocs_writecol_finish (aocsam.c:2907) apache#7 aocs_writecol_rewrite (aocsam.c:3954) (gdb) p desc->blockDirectory.blkdirRel $1 = (Relation) 0x7f7f7f7f7f7f7f7f i.e. never initialised, still holding palloc's fill pattern. Upstream says "the bug is covered by tests in subsequent commit", but that commit is not ported yet, so the reproducer is added to aoco_column_rewrite now rather than leaving the fix untested. Verified it has teeth by reverting the two lines and rerunning: the test fails with the QE connection dropping at the ALTER. Verified: AO/AOCS regression 24/24, AO isolation2 136/136 plus ao_partial_scan. uao/max_concurrency2_row failed in two of five full runs today and passed 3/3 standalone. It cannot be this commit: aocs_writecol_init() and aocs_writecol_finish() are reachable only through the AOCO table AM slots (aoco_relation_add_columns / aoco_relation_rewrite_columns), and that test uses ao_row. Both failures were in its "VACUUM in the presence of an old snapshot" section, which asserts exactly which segfiles got compacted versus left in AWAITING_DROP -- and the test opens 128 sessions and closes none of them, so the xmin horizon it vacuums against depends on how promptly 127 idle sessions' segment backends settle. Same family as the uao/brin_column and ao_partial_scan flakes already recorded.
yjhjstz
pushed a commit
to yjhjstz/cloudberry
that referenced
this pull request
Oct 27, 2026
(cherry picked from commit a48a9410123ebe3481ebfe66bef8f4bf4af14fff) aocs_writecol_finish() calls AppendOnlyBlockDirectory_End_writeCols() whenever the relation has a block directory, on the assumption that Init_writeCols() must have run. It need not have: aocs_writecol_rewrite() enters its loop on nseg >= 1 but skips every segfile whose total_tupcount is 0, so with a table that has segfiles but no live tuples, aocs_writecol_newsegfiles() -- and with it Init_writeCols() -- is never reached. palloc0 the descriptor and check blkdirRel before ending. This one does crash cbdb today. Reproducer: CREATE TABLE t(a int, b int) USING ao_column DISTRIBUTED BY (a); CREATE INDEX t_i ON t(a); -- makes blkdirrelid valid INSERT INTO t SELECT i,i FROM generate_series(1,10) i; DELETE FROM t; VACUUM t; -- segfiles remain, all empty ALTER TABLE t ALTER COLUMN b TYPE bigint; takes down the QE. Core confirms the cause exactly: apache#5 AppendOnlyBlockDirectory_End_writeCols (appendonlyblockdirectory.c:1793) apache#6 aocs_writecol_finish (aocsam.c:2907) apache#7 aocs_writecol_rewrite (aocsam.c:3954) (gdb) p desc->blockDirectory.blkdirRel $1 = (Relation) 0x7f7f7f7f7f7f7f7f i.e. never initialised, still holding palloc's fill pattern. Upstream says "the bug is covered by tests in subsequent commit", but that commit is not ported yet, so the reproducer is added to aoco_column_rewrite now rather than leaving the fix untested. Verified it has teeth by reverting the two lines and rerunning: the test fails with the QE connection dropping at the ALTER. Verified: AO/AOCS regression 24/24, AO isolation2 136/136 plus ao_partial_scan. uao/max_concurrency2_row failed in two of five full runs today and passed 3/3 standalone. It cannot be this commit: aocs_writecol_init() and aocs_writecol_finish() are reachable only through the AOCO table AM slots (aoco_relation_add_columns / aoco_relation_rewrite_columns), and that test uses ao_row. Both failures were in its "VACUUM in the presence of an old snapshot" section, which asserts exactly which segfiles got compacted versus left in AWAITING_DROP -- and the test opens 128 sessions and closes none of them, so the xmin horizon it vacuums against depends on how promptly 127 idle sessions' segment backends settle. Same family as the uao/brin_column and ao_partial_scan flakes already recorded.
yjhjstz
pushed a commit
to yjhjstz/cloudberry
that referenced
this pull request
Oct 27, 2026
(cherry picked from commit a48a9410123ebe3481ebfe66bef8f4bf4af14fff) aocs_writecol_finish() calls AppendOnlyBlockDirectory_End_writeCols() whenever the relation has a block directory, on the assumption that Init_writeCols() must have run. It need not have: aocs_writecol_rewrite() enters its loop on nseg >= 1 but skips every segfile whose total_tupcount is 0, so with a table that has segfiles but no live tuples, aocs_writecol_newsegfiles() -- and with it Init_writeCols() -- is never reached. palloc0 the descriptor and check blkdirRel before ending. This one does crash cbdb today. Reproducer: CREATE TABLE t(a int, b int) USING ao_column DISTRIBUTED BY (a); CREATE INDEX t_i ON t(a); -- makes blkdirrelid valid INSERT INTO t SELECT i,i FROM generate_series(1,10) i; DELETE FROM t; VACUUM t; -- segfiles remain, all empty ALTER TABLE t ALTER COLUMN b TYPE bigint; takes down the QE. Core confirms the cause exactly: apache#5 AppendOnlyBlockDirectory_End_writeCols (appendonlyblockdirectory.c:1793) apache#6 aocs_writecol_finish (aocsam.c:2907) apache#7 aocs_writecol_rewrite (aocsam.c:3954) (gdb) p desc->blockDirectory.blkdirRel $1 = (Relation) 0x7f7f7f7f7f7f7f7f i.e. never initialised, still holding palloc's fill pattern. Upstream says "the bug is covered by tests in subsequent commit", but that commit is not ported yet, so the reproducer is added to aoco_column_rewrite now rather than leaving the fix untested. Verified it has teeth by reverting the two lines and rerunning: the test fails with the QE connection dropping at the ALTER. Verified: AO/AOCS regression 24/24, AO isolation2 136/136 plus ao_partial_scan. uao/max_concurrency2_row failed in two of five full runs today and passed 3/3 standalone. It cannot be this commit: aocs_writecol_init() and aocs_writecol_finish() are reachable only through the AOCO table AM slots (aoco_relation_add_columns / aoco_relation_rewrite_columns), and that test uses ao_row. Both failures were in its "VACUUM in the presence of an old snapshot" section, which asserts exactly which segfiles got compacted versus left in AWAITING_DROP -- and the test opens 128 sessions and closes none of them, so the xmin horizon it vacuums against depends on how promptly 127 idle sessions' segment backends settle. Same family as the uao/brin_column and ao_partial_scan flakes already recorded.
tuhaihe
pushed a commit
that referenced
this pull request
Oct 28, 2026
UBSan reported an unaligned uint16 load while parsing tuple chunks. Copy the length into an aligned local with memcpy before adding the header size, preserving the existing native-endian interpretation. Sanitizer report (UBSan, instrumented build, distributed query with Motion traffic over UDP): ic_udpifc.c:4572:39: runtime error: load of misaligned address 0x52500016fa59 for type 'uint16', which requires 2 byte alignment #0 RecvTupleChunkUDPIFC ic_udpifc.c:4572 #1 receiveChunksUDPIFCLoop ic_udpifc.c:4462 #2 receiveChunksUDPIFC ic_udpifc.c:4406 #3 RecvTupleChunkFromAnyUDPIFC ic_udpifc.c:4739 #4 processIncomingChunks cdb/cdbmotion.c:653 #5 RecvTupleFrom cdbmotion.c:607 #6 execMotionUnsortedReceiver executor/nodeMotion.c:356 Reached whenever bytesProcessed walks the receive buffer past an even offset while splitting a message into tuple chunks. Benign on x86_64, but undefined behavior on strictly aligned targets.
reshke
added a commit
that referenced
this pull request
Oct 28, 2026
UBSan reported an unaligned uint64_t load in GpMurmurHash64A. Read each word with memcpy so input need not have uint64_t alignment, while preserving the little-endian hash computation. Sanitizer report (UBSan, instrumented build, ANALYZE on a table with short text values): gp_hyperloglog.c:897:11: runtime error: load of misaligned address 0x529000093515 for type 'uint64_t', which requires 8 byte alignment #0 GpMurmurHash64A gp_hyperloglog.c:897 #1 gp_hll_add_element gp_hyperloglog.c:471 #2 gp_hyperloglog_add_item gp_hyperloglog.c:788 #3 compute_scalar_stats commands/analyze.c:3968 #4 do_analyze_rel commands/analyze.c:971 #5 analyze_rel_internal commands/analyze.c:429 Triggered by ordinary ndistinct estimation during ANALYZE: short varlena values hashed via VARDATA_ANY have a payload offset that is not a multiple of 8. Benign on x86_64, but undefined behavior on strictly aligned targets.
yjhjstz
pushed a commit
to yjhjstz/cloudberry
that referenced
this pull request
Oct 28, 2026
(cherry picked from commit a48a9410123ebe3481ebfe66bef8f4bf4af14fff) aocs_writecol_finish() calls AppendOnlyBlockDirectory_End_writeCols() whenever the relation has a block directory, on the assumption that Init_writeCols() must have run. It need not have: aocs_writecol_rewrite() enters its loop on nseg >= 1 but skips every segfile whose total_tupcount is 0, so with a table that has segfiles but no live tuples, aocs_writecol_newsegfiles() -- and with it Init_writeCols() -- is never reached. palloc0 the descriptor and check blkdirRel before ending. This one does crash cbdb today. Reproducer: CREATE TABLE t(a int, b int) USING ao_column DISTRIBUTED BY (a); CREATE INDEX t_i ON t(a); -- makes blkdirrelid valid INSERT INTO t SELECT i,i FROM generate_series(1,10) i; DELETE FROM t; VACUUM t; -- segfiles remain, all empty ALTER TABLE t ALTER COLUMN b TYPE bigint; takes down the QE. Core confirms the cause exactly: apache#5 AppendOnlyBlockDirectory_End_writeCols (appendonlyblockdirectory.c:1793) apache#6 aocs_writecol_finish (aocsam.c:2907) apache#7 aocs_writecol_rewrite (aocsam.c:3954) (gdb) p desc->blockDirectory.blkdirRel $1 = (Relation) 0x7f7f7f7f7f7f7f7f i.e. never initialised, still holding palloc's fill pattern. Upstream says "the bug is covered by tests in subsequent commit", but that commit is not ported yet, so the reproducer is added to aoco_column_rewrite now rather than leaving the fix untested. Verified it has teeth by reverting the two lines and rerunning: the test fails with the QE connection dropping at the ALTER. Verified: AO/AOCS regression 24/24, AO isolation2 136/136 plus ao_partial_scan. uao/max_concurrency2_row failed in two of five full runs today and passed 3/3 standalone. It cannot be this commit: aocs_writecol_init() and aocs_writecol_finish() are reachable only through the AOCO table AM slots (aoco_relation_add_columns / aoco_relation_rewrite_columns), and that test uses ao_row. Both failures were in its "VACUUM in the presence of an old snapshot" section, which asserts exactly which segfiles got compacted versus left in AWAITING_DROP -- and the test opens 128 sessions and closes none of them, so the xmin horizon it vacuums against depends on how promptly 127 idle sessions' segment backends settle. Same family as the uao/brin_column and ao_partial_scan flakes already recorded.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Modify
Cloudberry InctoGreenplum Inccloses: issues/4
Change logs
Modify
Cloudberry InctoGreenplum IncWhy are the changes needed?
Open source licensing issues.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
make installcheck
Contributor's Checklist
Here are some reminders before you submit the pull request:
make installcheckmake -C src/test installcheck-cbdb-parallel