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
