[Bug] Specifying TAM for partiotion table

[reshke]

Cloudberry Database version

No response

What happened

the behavior of creating partitioned table inconsistently handles Table Access Method clause, because of

https://github.com/cloudberrydb/cloudberrydb/blob/main/src/backend/commands/tablecmds.c#L840

if dont really understand this if condition. In my opinion, we should not disallow this. Newly created partitions should inherit partition root TAM, aren't they? So we need a way to specify it.

What you think should happen instead

No response

How to reproduce

db3=# create table t(i int) partition by range (i) (start (10) end (11)) using ao_row distributed by (i) ;
CREATE TABLE
db3=# drop table t;
DROP TABLE
db3=# create table t(i int) partition by range (i)  using ao_row distributed by (i) ;
ERROR:  specifying a table access method is not supported on a partitioned table

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.

[reshke]

In both cases relkind = 'p' relation will be created.

[reshke]

To be clear: #695 does not fix this. In only handles how new partition will be created by saving into root partition pg_class.relam, not root partition definition. (this also would fail after 695 merged)

[gfphoenix78]

There are two kinds of partition tables in cloudberry. One is from greenplum, the other one inherits from postgres. The gp-style partition tables appear earlier than pg partition tables. When greenplum upgrade its kernel, the gp-style partition tables tends to implement with the pg partition code. The principle is that the behavior of partition tables try to follow the pg upstream, but also keep the legacy(gp-style) partition behaviors for existing customers.

db3=# create table t(i int) partition by range (i)  using ao_row distributed by (i) ;
ERROR:  specifying a table access method is not supported on a partitioned table

The syntax is from pg upstream, and the behavior is exactly the same as pg upstream. The root partition doesn't have access method, so the child can't inherit the access method from its parent.

When creating the gp-style partition tables, we try to keep the behavior, to allow the child partition inherits access method and other options from its parent partition. The result is that the root partition table saves its access method in pg_class.relam.

We don't plan to mix all things together to increase complexity.

[reshke]

There are two kinds of partition tables in cloudberry. One is from greenplum, the other one inherits from postgres. The gp-style partition tables appear earlier than pg partition tables. When greenplum upgrade its kernel, the gp-style partition tables tends to implement with the pg partition code. The principle is that the behavior of partition tables try to follow the pg upstream, but also keep the legacy(gp-style) partition behaviors for existing customers.

Sure, I know.

The syntax is from pg upstream, and the behavior is exactly the same as pg upstream. The root partition doesn't have access method, so the child can't inherit the access method from its parent.

Thats not true, and this is why this issue is created.

db2=# select version();
                                                 version
----------------------------------------------------------------------------------------------------------
 PostgreSQL 18devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
(1 row)

db2=# create access method am1 TYPE table HANDLER heap_tableam_handler;
CREATE ACCESS METHOD
db2=#
db2=# create table tt(i int) partition by range ( i ) using am1;
CREATE TABLE
db2=# select relam from pg_class where oid = 'tt'::regclass::oid;
 relam
-------
 16478
(1 row)

db2=# create table tt_p partition of tt
DEFAULT     FOR VALUES
db2=# create table tt_p partition of tt default ;
CREATE TABLE
db2=# select relam from pg_class where oid = 'tt_p'::regclass::oid;
 relam
-------
 16478
(1 row)

db2=#

[gfphoenix78]

There are two kinds of partition tables in cloudberry. One is from greenplum, the other one inherits from postgres. The gp-style partition tables appear earlier than pg partition tables. When greenplum upgrade its kernel, the gp-style partition tables tends to implement with the pg partition code. The principle is that the behavior of partition tables try to follow the pg upstream, but also keep the legacy(gp-style) partition behaviors for existing customers.

Sure, I know.

The syntax is from pg upstream, and the behavior is exactly the same as pg upstream. The root partition doesn't have access method, so the child can't inherit the access method from its parent.

Thats not true, and this is why this issue is created.

db2=# select version();
                                                 version
----------------------------------------------------------------------------------------------------------
 PostgreSQL 18devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
(1 row)

db2=# create access method am1 TYPE table HANDLER heap_tableam_handler;
CREATE ACCESS METHOD
db2=#
db2=# create table tt(i int) partition by range ( i ) using am1;
CREATE TABLE
db2=# select relam from pg_class where oid = 'tt'::regclass::oid;
 relam
-------
 16478
(1 row)

db2=# create table tt_p partition of tt
DEFAULT     FOR VALUES
db2=# create table tt_p partition of tt default ;
CREATE TABLE
db2=# select relam from pg_class where oid = 'tt_p'::regclass::oid;
 relam
-------
 16478
(1 row)

db2=#

The feature was first introduced in postgres 17. Before pg 17, the partition table isn't allowed to have table access method.
Normally, we'll have these features(from higher pg upstream) by upgrading the kernel.

[gfphoenix78]

Fixed by #695