Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Preserve extension dependencies on indexes during partition merge/split

  1. MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Kirill Reshke <reshkekirill@gmail.com> — 2026-03-10T17:53:46Z

    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?

-- 
Best regards,
Kirill Reshke

  2. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-03-11T15:12:49Z

    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

  3. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-04-07T14:14:05Z

    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

  4. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Dmitry Koval <d.koval@postgrespro.ru> — 2026-04-14T09:05:04Z

    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

  5. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-04-16T18:03:11Z

    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

  6. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Dmitry Koval <d.koval@postgrespro.ru> — 2026-04-20T00:04:28Z

    Hi Matheus!

 >v3-0001-Preserve-extension-dependencies-on-indexes-during.patch

I looked patch and did not find problems. But there is one point: 
extensions btree_gist, btree_gin, citext are not included by default.
So command

 > ./configure --enable-debug --enable-cassert --prefix `pwd`/install
 > >/dev/null && make -s && make install -s && make check

generates errors like

ERROR:  extension "btree_gist" is not available
ERROR:  extension "btree_gin" is not available
ERROR:  extension "citext" is not available

Might be it would be better to use for tests extensions from the
catalog src/test/modules/test_extensions (see test
src/test/modules/test_extensions/sql/test_extdepend.sql)?

 >extension dependencies on parent partitioned indexes don't seem to
 >prevent DROP EXTENSION, but dependencies on child partition indexes
 >do. ...

I agree, it looks strange ...


With best regards,
Dmitry Koval

Postgres Professional: http://postgrespro.com

  7. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-04-20T15:23:15Z

    On Sun Apr 19, 2026 at 9:04 PM -03, Dmitry Koval wrote:
> Hi Matheus!
>
>  >v3-0001-Preserve-extension-dependencies-on-indexes-during.patch
>
> I looked patch and did not find problems. But there is one point: 
> extensions btree_gist, btree_gin, citext are not included by default.
> So command
>
>  > ./configure --enable-debug --enable-cassert --prefix `pwd`/install
>  > >/dev/null && make -s && make install -s && make check
>
> generates errors like
>
> ERROR:  extension "btree_gist" is not available
> ERROR:  extension "btree_gin" is not available
> ERROR:  extension "citext" is not available
>
> Might be it would be better to use for tests extensions from the
> catalog src/test/modules/test_extensions (see test
> src/test/modules/test_extensions/sql/test_extdepend.sql)?
>

Thanks for looking at this!

Yeah, some build farm animals will not be happy with these new tests.
Fixed on new attached v4 to use extensions from
src/test/modules/test_extensions.

>  >extension dependencies on parent partitioned indexes don't seem to
>  >prevent DROP EXTENSION, but dependencies on child partition indexes
>  >do. ...
>
> I agree, it looks strange ...
>

I'll start a new thread to discuss this.

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

  8. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Alexander Korotkov <aekorotkov@gmail.com> — 2026-04-20T19:08:46Z

    On Thu, Apr 16, 2026 at 9:03 PM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
>
> 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

This is not obvious for me.  I would rather trigger an error if there
are different dependencies on merging partitions.

> 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.

Note that if you don't create explicit dependency then you would get
an error.  When you create an explicit dependency index => extension,
it's a different kind than the automatic one.  It causes index to be
dropped on extension drop (as documented).  Thus, if you create
dependency child_index => extension, then child_index gets dropped,
but parent_index automatic dependency still prevents deletion.  But if
you create dependency parent_index => extension then dropping of
extension trigger dropping of the parent_index, in turn that dropping
child_index.  So, everything is dropped, no errors.  I don't think
there is a bug.

------
Regards,
Alexander Korotkov
Supabase

  9. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-04-21T13:20:50Z

    On Mon Apr 20, 2026 at 4:08 PM -03, Alexander Korotkov wrote:
> On Thu, Apr 16, 2026 at 9:03 PM Matheus Alcantara
> <matheusssilv97@gmail.com> wrote:
>>
>> 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
>
> This is not obvious for me.  I would rather trigger an error if there
> are different dependencies on merging partitions.
>

Yeah, I agree that this sounds a bit confusing, although this behavior
is documented on the last patch version I think that raising an error is
more simple and maybe is more obvious. The attached patch implement
this.

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

  10. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Alexander Korotkov <aekorotkov@gmail.com> — 2026-04-21T15:57:33Z

    Hi!

On Tue, Apr 21, 2026 at 4:20 PM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
> On Mon Apr 20, 2026 at 4:08 PM -03, Alexander Korotkov wrote:
> > On Thu, Apr 16, 2026 at 9:03 PM Matheus Alcantara
> > <matheusssilv97@gmail.com> wrote:
> >>
> >> 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
> >
> > This is not obvious for me.  I would rather trigger an error if there
> > are different dependencies on merging partitions.
> >
>
> Yeah, I agree that this sounds a bit confusing, although this behavior
> is documented on the last patch version I think that raising an error is
> more simple and maybe is more obvious. The attached patch implement
> this.

I've spotted the following things in this patch.
1) The equality of dependencies is not fully checked.  We only check
that for each new dependency, we have the same for previous partition,
but not vise versa.
2) The complexity of dependency checking is O(n^2).
3) Usage of citext and other extensions in src/test/regress where they
might be not available.

I've revised the patch.
1) collectPartitionIndexExtDeps() is rewritten().  Now it works in
three phases: collect, sort, compare.  The comparison phase requires
strict equivalence of dependencies and doesn't depend on the order.
The complexity is now O(n * log(n)), which I think is acceptable.
2) PartitionIndexExtDepEntry struct now have indexOid.  So, on
conflict error contains both partition index names.
3) Tests moved to
src/test/modules/test_extensions/sql/test_extdepend.sql where
test_ext3/test_ext5 extensions are available.
4) More tests for different scenarios.

Could you, please, review this changes?

------
Regards,
Alexander Korotkov
Supabase

  11. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-04-21T19:23:33Z

    On 21/04/26 12:57, Alexander Korotkov wrote:
> I've spotted the following things in this patch.
> 1) The equality of dependencies is not fully checked.  We only check
> that for each new dependency, we have the same for previous partition,
> but not vise versa.
> 2) The complexity of dependency checking is O(n^2).
> 3) Usage of citext and other extensions in src/test/regress where they
> might be not available.
> 

Oops, I forgot to replace the citext extension on split partition tests.

> I've revised the patch.
> 1) collectPartitionIndexExtDeps() is rewritten().  Now it works in
> three phases: collect, sort, compare.  The comparison phase requires
> strict equivalence of dependencies and doesn't depend on the order.
> The complexity is now O(n * log(n)), which I think is acceptable.
> 2) PartitionIndexExtDepEntry struct now have indexOid.  So, on
> conflict error contains both partition index names.
> 3) Tests moved to
> src/test/modules/test_extensions/sql/test_extdepend.sql where
> test_ext3/test_ext5 extensions are available.
> 4) More tests for different scenarios.
> 
> Could you, please, review this changes?
> 

I think that you miss to include the patch?

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

  12. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Alexander Korotkov <aekorotkov@gmail.com> — 2026-04-21T19:35:28Z

    On Tue, Apr 21, 2026 at 10:23 PM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
> On 21/04/26 12:57, Alexander Korotkov wrote:
> > I've spotted the following things in this patch.
> > 1) The equality of dependencies is not fully checked.  We only check
> > that for each new dependency, we have the same for previous partition,
> > but not vise versa.
> > 2) The complexity of dependency checking is O(n^2).
> > 3) Usage of citext and other extensions in src/test/regress where they
> > might be not available.
> >
>
> Oops, I forgot to replace the citext extension on split partition tests.
>
> > I've revised the patch.
> > 1) collectPartitionIndexExtDeps() is rewritten().  Now it works in
> > three phases: collect, sort, compare.  The comparison phase requires
> > strict equivalence of dependencies and doesn't depend on the order.
> > The complexity is now O(n * log(n)), which I think is acceptable.
> > 2) PartitionIndexExtDepEntry struct now have indexOid.  So, on
> > conflict error contains both partition index names.
> > 3) Tests moved to
> > src/test/modules/test_extensions/sql/test_extdepend.sql where
> > test_ext3/test_ext5 extensions are available.
> > 4) More tests for different scenarios.
> >
> > Could you, please, review this changes?
> >
>
> I think that you miss to include the patch?

Yep, here it is.

------
Regards,
Alexander Korotkov
Supabase

  13. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Kirill Reshke <reshkekirill@gmail.com> — 2026-04-22T10:48:18Z

    On Wed, 22 Apr 2026 at 00:35, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> On Tue, Apr 21, 2026 at 10:23 PM Matheus Alcantara
> <matheusssilv97@gmail.com> wrote:
> > On 21/04/26 12:57, Alexander Korotkov wrote:
> > > I've spotted the following things in this patch.
> > > 1) The equality of dependencies is not fully checked.  We only check
> > > that for each new dependency, we have the same for previous partition,
> > > but not vise versa.
> > > 2) The complexity of dependency checking is O(n^2).
> > > 3) Usage of citext and other extensions in src/test/regress where they
> > > might be not available.
> > >
> >
> > Oops, I forgot to replace the citext extension on split partition tests.
> >
> > > I've revised the patch.
> > > 1) collectPartitionIndexExtDeps() is rewritten().  Now it works in
> > > three phases: collect, sort, compare.  The comparison phase requires
> > > strict equivalence of dependencies and doesn't depend on the order.
> > > The complexity is now O(n * log(n)), which I think is acceptable.
> > > 2) PartitionIndexExtDepEntry struct now have indexOid.  So, on
> > > conflict error contains both partition index names.
> > > 3) Tests moved to
> > > src/test/modules/test_extensions/sql/test_extdepend.sql where
> > > test_ext3/test_ext5 extensions are available.
> > > 4) More tests for different scenarios.
> > >
> > > Could you, please, review this changes?
> > >
> >
> > I think that you miss to include the patch?
>
> Yep, here it is.
>
> ------
> Regards,
> Alexander Korotkov
> Supabase


Hi!
So, we only transfer dependencies on partitioned indexes when
SPLIT/MERGE partitions, not tables themselves (this is what this
thread started from).
I think this is correct.

Some minor comments:

> +-- Sanity check: the extension can't be dropped while dependencies exist.
>+DROP EXTENSION test_ext3;

This exercises something that already works on HEAD (note this is DROP
before first MERGE partition call ). Do we really need this?

>
> +-- An index created directly on a partition has no parent in the partitioned
> +-- index tree; merge must ignore such indexes (they disappear with the old
> +-- partition).
> +CREATE INDEX part_extdep_3_extra_idx ON part_extdep_3(x);
> +ALTER TABLE part_extdep MERGE PARTITIONS (part_extdep_merged, part_extdep_3)
> +    INTO part_extdep_merged2;
> +SELECT relname FROM pg_class
> +WHERE relname LIKE 'part_extdep_merged2%idx' ORDER BY relname;

Looks like this test is also redundant? This does not test new DEPENDS ON logic.


Otherwise LGTM

-- 
Best regards,
Kirill Reshke

  14. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-04-22T10:53:04Z

    On Tue Apr 21, 2026 at 4:35 PM -03, Alexander Korotkov wrote:
>> > I've revised the patch.
>> > 1) collectPartitionIndexExtDeps() is rewritten().  Now it works in
>> > three phases: collect, sort, compare.  The comparison phase requires
>> > strict equivalence of dependencies and doesn't depend on the order.
>> > The complexity is now O(n * log(n)), which I think is acceptable.
>> > 2) PartitionIndexExtDepEntry struct now have indexOid.  So, on
>> > conflict error contains both partition index names.
>> > 3) Tests moved to
>> > src/test/modules/test_extensions/sql/test_extdepend.sql where
>> > test_ext3/test_ext5 extensions are available.
>> > 4) More tests for different scenarios.
>> >
>> > Could you, please, review this changes?
>> >
>>
>> I think that you miss to include the patch?
>
> Yep, here it is.
>

Thanks for the patch. It looks good to me, and I confirm that it fix the
issues that I miss on the previous version.

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

  15. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-04-22T10:58:06Z

    On Wed Apr 22, 2026 at 7:48 AM -03, Kirill Reshke wrote:
>> +-- An index created directly on a partition has no parent in the partitioned
>> +-- index tree; merge must ignore such indexes (they disappear with the old
>> +-- partition).
>> +CREATE INDEX part_extdep_3_extra_idx ON part_extdep_3(x);
>> +ALTER TABLE part_extdep MERGE PARTITIONS (part_extdep_merged, part_extdep_3)
>> +    INTO part_extdep_merged2;
>> +SELECT relname FROM pg_class
>> +WHERE relname LIKE 'part_extdep_merged2%idx' ORDER BY relname;
>
> Looks like this test is also redundant? This does not test new DEPENDS ON logic.
>

I think that this test is useful to ensure that we correctly skip such
indexes created directly on a specific partition. Perhaps we can include
an ALTER INDEX ... DEPENDS ON for this specific index to make it more
consistent with the other tests?

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

  16. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Kirill Reshke <reshkekirill@gmail.com> — 2026-04-22T10:59:22Z

    On Wed, 22 Apr 2026 at 15:58, Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
>
> On Wed Apr 22, 2026 at 7:48 AM -03, Kirill Reshke wrote:
> >> +-- An index created directly on a partition has no parent in the partitioned
> >> +-- index tree; merge must ignore such indexes (they disappear with the old
> >> +-- partition).
> >> +CREATE INDEX part_extdep_3_extra_idx ON part_extdep_3(x);
> >> +ALTER TABLE part_extdep MERGE PARTITIONS (part_extdep_merged, part_extdep_3)
> >> +    INTO part_extdep_merged2;
> >> +SELECT relname FROM pg_class
> >> +WHERE relname LIKE 'part_extdep_merged2%idx' ORDER BY relname;
> >
> > Looks like this test is also redundant? This does not test new DEPENDS ON logic.
> >
>
> I think that this test is useful to ensure that we correctly skip such
> indexes created directly on a specific partition. Perhaps we can include
> an ALTER INDEX ... DEPENDS ON for this specific index to make it more
> consistent with the other tests?
>
> --
> Matheus Alcantara
> EDB: https://www.enterprisedb.com

This test is maybe useful, but this is unrelated to what this thread &
fix is about, for my taste.

-- 
Best regards,
Kirill Reshke

  17. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-04-22T11:05:47Z

    On Wed Apr 22, 2026 at 7:59 AM -03, Kirill Reshke wrote:
> On Wed, 22 Apr 2026 at 15:58, Matheus Alcantara
> <matheusssilv97@gmail.com> wrote:
>>
>> On Wed Apr 22, 2026 at 7:48 AM -03, Kirill Reshke wrote:
>> >> +-- An index created directly on a partition has no parent in the partitioned
>> >> +-- index tree; merge must ignore such indexes (they disappear with the old
>> >> +-- partition).
>> >> +CREATE INDEX part_extdep_3_extra_idx ON part_extdep_3(x);
>> >> +ALTER TABLE part_extdep MERGE PARTITIONS (part_extdep_merged, part_extdep_3)
>> >> +    INTO part_extdep_merged2;
>> >> +SELECT relname FROM pg_class
>> >> +WHERE relname LIKE 'part_extdep_merged2%idx' ORDER BY relname;
>> >
>> > Looks like this test is also redundant? This does not test new DEPENDS ON logic.
>> >
>>
>> I think that this test is useful to ensure that we correctly skip such
>> indexes created directly on a specific partition. Perhaps we can include
>> an ALTER INDEX ... DEPENDS ON for this specific index to make it more
>> consistent with the other tests?
>
> This test is maybe useful, but this is unrelated to what this thread &
> fix is about, for my taste.
>

On collectPartitionIndexExtDeps() we have:
    if (!get_rel_relispartition(indexOid))
        continue;

    parentIndexOid = get_partition_parent(indexOid, true);
    if (!OidIsValid(parentIndexOid))
        continue;

I think that this test ensure that get_rel_relispartition() check is
called, otherwise we will call get_partition_parent() with an index that
don't have parent which will fail with an elog(ERROR).

It can be unrelated but I think that it ensure correctness for this fix,
or I'm missing something here?

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

  18. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Alexander Korotkov <aekorotkov@gmail.com> — 2026-04-22T11:24:29Z

    On Wed, Apr 22, 2026 at 1:48 PM Kirill Reshke <reshkekirill@gmail.com> wrote:
> Some minor comments:
>
> > +-- Sanity check: the extension can't be dropped while dependencies exist.
> >+DROP EXTENSION test_ext3;
>
> This exercises something that already works on HEAD (note this is DROP
> before first MERGE partition call ). Do we really need this?

I've removed this.

> > +-- An index created directly on a partition has no parent in the partitioned
> > +-- index tree; merge must ignore such indexes (they disappear with the old
> > +-- partition).
> > +CREATE INDEX part_extdep_3_extra_idx ON part_extdep_3(x);
> > +ALTER TABLE part_extdep MERGE PARTITIONS (part_extdep_merged, part_extdep_3)
> > +    INTO part_extdep_merged2;
> > +SELECT relname FROM pg_class
> > +WHERE relname LIKE 'part_extdep_merged2%idx' ORDER BY relname;
>
> Looks like this test is also redundant? This does not test new DEPENDS ON logic.

I've added the dependency on this index to check index disappears with
its dependency.  I think this would make this test more relevant.

Kirill, Matheus, are you ok with these change?

------
Regards,
Alexander Korotkov
Supabase

  19. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Kirill Reshke <reshkekirill@gmail.com> — 2026-04-22T11:26:43Z

    On Wed, 22 Apr 2026 at 16:24, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> On Wed, Apr 22, 2026 at 1:48 PM Kirill Reshke <reshkekirill@gmail.com> wrote:
> > Some minor comments:
> >
> > > +-- Sanity check: the extension can't be dropped while dependencies exist.
> > >+DROP EXTENSION test_ext3;
> >
> > This exercises something that already works on HEAD (note this is DROP
> > before first MERGE partition call ). Do we really need this?
>
> I've removed this.
>
> > > +-- An index created directly on a partition has no parent in the partitioned
> > > +-- index tree; merge must ignore such indexes (they disappear with the old
> > > +-- partition).
> > > +CREATE INDEX part_extdep_3_extra_idx ON part_extdep_3(x);
> > > +ALTER TABLE part_extdep MERGE PARTITIONS (part_extdep_merged, part_extdep_3)
> > > +    INTO part_extdep_merged2;
> > > +SELECT relname FROM pg_class
> > > +WHERE relname LIKE 'part_extdep_merged2%idx' ORDER BY relname;
> >
> > Looks like this test is also redundant? This does not test new DEPENDS ON logic.
>
> I've added the dependency on this index to check index disappears with
> its dependency.  I think this would make this test more relevant.
>
> Kirill, Matheus, are you ok with these change?
>
> ------
> Regards,
> Alexander Korotkov
> Supabase

v7 WFM

-- 
Best regards,
Kirill Reshke

  20. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-04-22T11:30:17Z

    On 22/04/26 08:24, Alexander Korotkov wrote:
>>> +-- An index created directly on a partition has no parent in the partitioned
>>> +-- index tree; merge must ignore such indexes (they disappear with the old
>>> +-- partition).
>>> +CREATE INDEX part_extdep_3_extra_idx ON part_extdep_3(x);
>>> +ALTER TABLE part_extdep MERGE PARTITIONS (part_extdep_merged, part_extdep_3)
>>> +    INTO part_extdep_merged2;
>>> +SELECT relname FROM pg_class
>>> +WHERE relname LIKE 'part_extdep_merged2%idx' ORDER BY relname;
>>
>> Looks like this test is also redundant? This does not test new DEPENDS ON logic.
> 
> I've added the dependency on this index to check index disappears with
> its dependency.  I think this would make this test more relevant.
> 
> Kirill, Matheus, are you ok with these change?
> 
It works for me.

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

  21. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Alexander Korotkov <aekorotkov@gmail.com> — 2026-04-22T11:34:57Z

    On Wed, Apr 22, 2026 at 2:30 PM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
> On 22/04/26 08:24, Alexander Korotkov wrote:
> >>> +-- An index created directly on a partition has no parent in the partitioned
> >>> +-- index tree; merge must ignore such indexes (they disappear with the old
> >>> +-- partition).
> >>> +CREATE INDEX part_extdep_3_extra_idx ON part_extdep_3(x);
> >>> +ALTER TABLE part_extdep MERGE PARTITIONS (part_extdep_merged, part_extdep_3)
> >>> +    INTO part_extdep_merged2;
> >>> +SELECT relname FROM pg_class
> >>> +WHERE relname LIKE 'part_extdep_merged2%idx' ORDER BY relname;
> >>
> >> Looks like this test is also redundant? This does not test new DEPENDS ON logic.
> >
> > I've added the dependency on this index to check index disappears with
> > its dependency.  I think this would make this test more relevant.
> >
> > Kirill, Matheus, are you ok with these change?
> >
> It works for me.

Thank you, pushed!

------
Regards,
Alexander Korotkov
Supabase

  22. Re: MERGE PARTITIONS and DEPENDS ON EXTENSION.

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-04-22T11:42:23Z

    On 22/04/26 08:34, Alexander Korotkov wrote:
> On Wed, Apr 22, 2026 at 2:30 PM Matheus Alcantara
> <matheusssilv97@gmail.com> wrote:
>> On 22/04/26 08:24, Alexander Korotkov wrote:
>>>>> +-- An index created directly on a partition has no parent in the partitioned
>>>>> +-- index tree; merge must ignore such indexes (they disappear with the old
>>>>> +-- partition).
>>>>> +CREATE INDEX part_extdep_3_extra_idx ON part_extdep_3(x);
>>>>> +ALTER TABLE part_extdep MERGE PARTITIONS (part_extdep_merged, part_extdep_3)
>>>>> +    INTO part_extdep_merged2;
>>>>> +SELECT relname FROM pg_class
>>>>> +WHERE relname LIKE 'part_extdep_merged2%idx' ORDER BY relname;
>>>>
>>>> Looks like this test is also redundant? This does not test new DEPENDS ON logic.
>>>
>>> I've added the dependency on this index to check index disappears with
>>> its dependency.  I think this would make this test more relevant.
>>>
>>> Kirill, Matheus, are you ok with these change?
>>>
>> It works for me.
> 
> Thank you, pushed!
> 

Thank you!

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