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)
