Re: DROP INVALID INDEXES command

Hello,

On 2026-Jul-03, Roman Khapov wrote:

> Did v3 with new function - pg_drop_invalid_indexes, for now without
> support of skip locked logic, due we currently have no agreement
> about it..

Two questions,

1. what are you expecting to cascade on? I don't remember offhand if
anything can depend on an invalid index, but seeing how you have no
tests for that case, I am inclined to suggest removing that argument
and code altogether (so it should be DROP_RESTRICT).

2. Why do you release the AEL after looking at indisvalid? I think
whatever lock you obtain should be kept until the end of the
transaction, as is normal for all DDL. In this coding, you take AEL
on all indexes first, then unlock all indexes, and lastly acquire AEL
again for performMultipleDeletions. Seems not optimal.

In fact the logic is convoluted for no good reason; or rather the reason
seems to be that you wanted to reuse RelationGetIndexList. Maybe it'd
be better to have your own pg_index scan instead.

You seem to have done nothing about partitioned tables, as I mentioned
earlier.

What does this comment mean?

+# This pauses on the injection point while populating catcache list
+# for functions with name "foofunc"

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Right now the sectors on the hard disk run clockwise, but I heard a rumor that
you can squeeze 0.2% more throughput by running them counterclockwise.
It's worth the effort. Recommended." (Gerry Pourwelle)