Re: Does a cancelled REINDEX CONCURRENTLY need to be messy? - Mailing list pgsql-hackers

From Andreas Karlsson
Subject Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?
Date
Msg-id 3c731352-3fbc-c98e-11af-ef5075de584e@proxel.se
Whole thread Raw
In response to Does a cancelled REINDEX CONCURRENTLY need to be messy?  (Thom Brown <thom@linux.com>)
Responses Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?
List pgsql-hackers
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.

Andreas




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: tablecmds.c/MergeAttributes() cleanup
Next
From: Tom Lane
Date:
Subject: Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?