Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?
Date: 2023-06-29 11:04:25
Message-ID: 3c731352-3fbc-c98e-11af-ef5075de584e@proxel.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-06-29 11:17:49 Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?
Previous Message Alvaro Herrera 2023-06-29 11:03:41 Re: tablecmds.c/MergeAttributes() cleanup