Andreas Karlsson <andreas@proxel.se> writes:
> On 6/29/23 11:13, Thom Brown wrote:
>> I get the feeling that this is deliberate, and perhaps an attempt to
>> mitigate locking issues, or some other explanation, but the rationale
>> isn't immediately apparent to me if this is the case.
> I have always assumed the reason is that there might be other
> transactions using the index so if we are going to drop it on rollback
> we might get stuck forever waiting for an exclusive lock on the index.
> How do you get around that? Rollback being stuck waiting forever is
> certainly not a nice behavior.
Right. The whole point of CONCURRENTLY is to never take an exclusive
lock. But once we reach the stage where the index is open for other
transactions to insert into, it's difficult to back out in a nice way.
Now that we have DROP INDEX CONCURRENTLY, you could imagine switching
into that code path --- but that *also* involves waiting for other
transactions, so you still have the problem that the transaction may
appear to be stuck and not responding to cancel.
(IIRC, cancelling DROP INDEX CONCURRENTLY also leads to a messy
situation, in that the index is still there but might not be fully
functional.)
regards, tom lane
