[Bug] VACUUM causes SIGSEGV (freespace.c:637) on first run for tables in non-default tablespace

[avamingli]

Apache Cloudberry version

main

What happened

Running VACUUM ANALYZE on a heap table (or any AO table whose auxiliary
aoseg table is) stored in a non-default tablespace crashes a segment
with a segmentation fault on the first vacuum execution (before the FSM
and VM forks have ever been created).

What you think should happen instead

No response

How to reproduce

-- 1. Create a non-default tablespace                                                                                               CREATE TABLESPACE crash_ts LOCATION '/tmp/crash_ts_dir';

-- 2. Create a heap table in it and insert data
CREATE TABLE t (id int, val text) TABLESPACE crash_ts DISTRIBUTED BY (id);
INSERT INTO t SELECT i, repeat('x', 80) FROM generate_series(1, 500) i;

-- 3. Run VACUUM for the first time  ← crashes
VACUUM ANALYZE t;

The same crash occurs with an AO table, because vacuum_rel recursively
vacuums the aoseg auxiliary heap table, which lives in the same non-default
tablespace.

Observed Behavior

A segment process crashes with SIGSEGV. The coordinator reports:

ERROR: Error on receive from seg2 127.0.0.1:XXXXX pid=NNNN:
server closed the connection unexpectedly

Core backtrace:

  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  fsm_extend (rel=..., fsm_nblocks=3) at freespace.c:637
  #1  fsm_readbuf (...) at freespace.c:561
  #2  fsm_set_and_search (...) at freespace.c:667
  #3  RecordPageWithFreeSpace (...) at freespace.c:192
  #4  lazy_scan_heap (...) at vacuumlazy.c:1599
  #5  heap_vacuum_rel (...) at vacuumlazy.c:664
  #6  table_relation_vacuum (...) at tableam.h:1923
  #7  vacuum_rel (relid=<aoseg oid>, ...) at vacuum.c:2727
  #8  vacuum_rel (relid=<ao table oid>, ...) at vacuum.c:2817   ← AO case

Operating System

any

Anything else

No response

Are you willing to submit PR?

• Yes, I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct.