[Bug] Cursors / extended-protocol queries leak one DSM segment each until transaction end: "too many dynamic shared memory segments" #2165

Apache Cloudberry version

Version: Apache Cloudberry 2.1.0-incubating (built from the tag), Debian 13.

What happened

Every query dispatched through a portal with is_extended_query (a DECLARE CURSOR, or Bind/Execute over the extended protocol) makes the QD call verify_shared_snapshot_ready() → dumpSharedLocalSnapshot_forCursor(), which does a fresh dsm_create() (utils/time/sharedsnapshot.c:640). The segments are owned by the session-level DumpResOwner and only released in AtEOXact_SharedSnapshot(). The dump index is a 32-entry ring (SNAPSHOTDUMPARRAYSZ), but overwriting an entry does not release the old segment. So a single transaction can run at most about 64 + 9*MaxBackends such queries; the next one fails.

What you think should happen instead

No response

How to reproduce

Repro (psql only), with ~N AO tables where N > 64 + 9*MaxBackends (here 3100 tables vs a limit of 2584):

CREATE DATABASE dsmtest;  -- then, one table per statement:
SELECT format('CREATE TABLE t_%s (id int) WITH (appendoptimized=true) DISTRIBUTED BY (id); INSERT INTO t_%s VALUES (1);', i, i)
FROM generate_series(1, 3100) i \gexec

BEGIN;
SELECT format('DECLARE c CURSOR FOR SELECT COALESCE(sum(modcount),0) FROM gp_dist_random(%L)', segrelid::regclass),
       'FETCH 1 FROM c',
       'CLOSE c'
FROM pg_appendonly \gexec
-- ERROR:  too many dynamic shared memory segments

ls /dev/shm | grep -c '^PostgreSQL.' on the coordinator grows by one per cursor (4 → 2462) and drops back on abort. The same queries without a cursor pass, also under REPEATABLE READ and with pg_export_snapshot(). With pgbench and the same script in one transaction: -M simple passes, -M extended and -M prepared fail after ~2580 queries.

Operating System

Debian GNU/Linux 13 (trixie)

Anything else

We hit this during the gpbackup with enabled --leaf-partition-data
gpbackup --leaf-partition-data (pgx v5, extended protocol) runs one gp_dist_random modcount query per AO table in its single transaction, so a full backup of a database with more AO tables than the limit always fails (ours: 13,461 AO tables).

Also reproduced the same issue with pgbackup / psql / pgbench on lab cluster with 4 primary segments and 3100 AO tables.

Possible fixes: skip the dump when the snapshot did not change since the previous one, or release the segment of the ring entry being overwritten (whether readers can still need it is for you to judge).

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.