MERGE PARTITIONS and DEPENDS ON EXTENSION.

Hi,

On 10/03/26 14:53, Kirill Reshke wrote:

Today, while reviewing another patch, I spotted PostgreSQL behaviour
which I cannot tell if is correct.

-- create relation
reshke=# create table pt (i int) partition by range ( i);
CREATE TABLE

-- create partitions.
reshke=# create table pt1 partition of pt for values from ( 1 ) to (2) ;
CREATE TABLE
reshke=# create table pt2 partition of pt for values from ( 2 ) to (3) ;
CREATE TABLE

-- manually add dependency on extension.
reshke=# alter index pt1_i_idx depends on extension btree_gist ;
ALTER INDEX
reshke=# alter index pt2_i_idx depends on extension btree_gist ;
ALTER INDEX

At this point, `drop extension btree_gist` fails due to existing
dependencies. However, after `alter table pt merge partitions ( pt1 ,
pt2 ) into pt3;` there are no dependencies, and drop extension
executes successfully.

My first impression was that there is no issue as the user created a
new database object, so should manually add dependency on extension.
However I am not 100% in this reasoning.

Any thoughts?

I'm also not sure if it's correct to assume that the dependency should
be manually added after a partition is merged or splited but I was
checking ATExecMergePartitions() and ATExecSplitPartition() and I
think that it's not complicated to implement this.

IIUC we just need to collect the extension dependencies before an
index is detached on MERGE and SPLIT operations and then apply the
dependency after the index is created on the new merged/splited
partition. The attached patch implement this.

Note that I'm using two different extensions for partition_merge and
partition_split tests because I was having deadlock issues when
running these tests in parallel using the same extension as a dependency.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

On Wed Mar 11, 2026 at 12:12 PM -03, Matheus Alcantara wrote:

On 10/03/26 14:53, Kirill Reshke wrote:

Today, while reviewing another patch, I spotted PostgreSQL behaviour
which I cannot tell if is correct.

-- create relation
reshke=# create table pt (i int) partition by range ( i);
CREATE TABLE

-- create partitions.
reshke=# create table pt1 partition of pt for values from ( 1 ) to (2) ;
CREATE TABLE
reshke=# create table pt2 partition of pt for values from ( 2 ) to (3) ;
CREATE TABLE

-- manually add dependency on extension.
reshke=# alter index pt1_i_idx depends on extension btree_gist ;
ALTER INDEX
reshke=# alter index pt2_i_idx depends on extension btree_gist ;
ALTER INDEX

At this point, `drop extension btree_gist` fails due to existing
dependencies. However, after `alter table pt merge partitions ( pt1 ,
pt2 ) into pt3;` there are no dependencies, and drop extension
executes successfully.

My first impression was that there is no issue as the user created a
new database object, so should manually add dependency on extension.
However I am not 100% in this reasoning.

Any thoughts?

I'm also not sure if it's correct to assume that the dependency should
be manually added after a partition is merged or splited but I was
checking ATExecMergePartitions() and ATExecSplitPartition() and I
think that it's not complicated to implement this.

IIUC we just need to collect the extension dependencies before an
index is detached on MERGE and SPLIT operations and then apply the
dependency after the index is created on the new merged/splited
partition. The attached patch implement this.

Note that I'm using two different extensions for partition_merge and
partition_split tests because I was having deadlock issues when
running these tests in parallel using the same extension as a dependency.

Attaching a new rebased version, no changes compared with v1.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

Hi Matheus!

Thank you for patch.
I agree that dependency should be automatically added for SPLIT
PARTITION. But I'm not sure about MERGE PARTITION ...
Might be it would be more correct to automatically add a dependency only
if all merged partitions have it?

--
With best regards,
Dmitry Koval

Postgres Professional: http://postgrespro.com

On Tue Apr 14, 2026 at 6:05 AM -03, Dmitry Koval wrote:

Hi Matheus!

Thank you for patch.
I agree that dependency should be automatically added for SPLIT
PARTITION. But I'm not sure about MERGE PARTITION ...
Might be it would be more correct to automatically add a dependency only
if all merged partitions have it?

Hi,

Thank you for taking a look on this!

I agree with your suggestion. The attached patch implements the
intersection behavior for MERGE PARTITIONS: extension dependencies are
only preserved on the merged partition's index if all source partition
indexes have that dependency.

For example:
MERGE(idx1(ext_a, ext_b), idx2(ext_a)) -> idx3(ext_a) -- only ext_a is common
MERGE(idx1(ext_a), idx2()) -> idx3() -- no common deps

For SPLIT PARTITION, the behavior remains the same since there's only
one source partition, all its extension dependencies are copied to the
new partition indexes.

While working on this patch, I noticed what might be a separate bug (or
perhaps intentional behavior that I don't understand): extension
dependencies on parent partitioned indexes don't seem to prevent DROP
EXTENSION, but dependencies on child partition indexes do. See this
example:

CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE t (i int) PARTITION BY RANGE (i);
CREATE TABLE t_1 PARTITION OF t FOR VALUES FROM (1) TO (2);
CREATE INDEX t_idx ON t USING gist (i);

-- Add dependency on the PARENT partitioned index
ALTER INDEX t_idx DEPENDS ON EXTENSION btree_gist;

-- This succeeds (I expected it to fail):
DROP EXTENSION btree_gist;

But if I add the dependency on the child partition index instead:

ALTER INDEX t_1_i_idx DEPENDS ON EXTENSION btree_gist;

DROP EXTENSION btree_gist;
ERROR: cannot drop extension btree_gist because other objects depend on it
DETAIL: index t_idx depends on operator class gist_int4_ops for access method gist

Is this expected behavior, or a separate bug? I would have expected the
dependency on the parent index to also prevent the DROP.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com