[Bug] Insert into a ao relation with 32 concurrent transactions failled

[shmiwy]

Cloudberry Database version

No response

What happened

setup

SET gp_create_table_random_default_distribution=off;
DROP TABLE IF EXISTS ao;
CREATE TABLE ao (a INT, b INT) WITH (appendonly=true);

For each concurrency, just use the following query.

SET optimizer=off;
begin;
INSERT INTO AO VALUES (1, 1);
COMMIT;

The system will report an error

INSERT INTO AO VALUES (1, 1); 
ERROR:  could not find segment file to use for inserting into relation "ao"  (seg1 127.0.1.1:7003 pid=6821)

What you think should happen instead

The system must not report errors

How to reproduce

rerun the query with 32 concurrent transactions

Operating System

centos7

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.

[avamingli]

This is not a bug, it's designed by GPDB, there are 128 ao segfiles at most while 0 segfile is used for utility mode.
limit 128 files because TupleID for ao table is composed by [segfileno, rowno, flags] and the size is same with a TupleID for heap tables. It's a tradeoff of concurrent write process and rowno for ao tables.

[shmiwy]

But for now, the above problem occurs when the concurrency reaches 32. @avamingli

[avamingli]

bug for now, the above problem occurs when the concurrency reaches 33. @avamingli

I guess the reason is GUC gp_appendonly_insert_files is changed to 4 by default, it's designed for parallel. Also a tradeoff between concurrent processes and segfiles for parallel.
Show that GUC and set it to 1, have a check.

[shmiwy]

In my env

gpadmin=# show gp_appendonly_insert_files;
 gp_appendonly_insert_files
----------------------------
 4

I try to change the GUC and try again.