On 03.07.23 19:46, Álvaro Herrera wrote:
Well, I definitely agree that it would be useful to have*something*
that automatically removes debris
Yeah, like "undo".
On 2023-Jul-04, Michael Paquier wrote:
> On Mon, Jul 03, 2023 at 07:46:27PM +0200, Alvaro Herrera wrote:
> > Perhaps we could have autovacuum check for it, and do it
> > separately of vacuum proper.)
>
> Being able to reuse some of the worker/launcher parts from autovacuum
> could make things
On Mon, Jul 03, 2023 at 07:46:27PM +0200, Alvaro Herrera wrote:
> On 2023-Jul-01, Thom Brown wrote:
>> On Thu, 29 Jun 2023, 14:45 Álvaro Herrera, wrote:
>>> ALTER TABLE DETACH CONCURRENTLY had to deal with this also, and it did it
>>> by having a COMPLETE option you can run later in case things
On 2023-Jul-01, Thom Brown wrote:
> On Thu, 29 Jun 2023, 14:45 Álvaro Herrera, wrote:
>
> > ALTER TABLE DETACH CONCURRENTLY had to deal with this also, and it did it
> > by having a COMPLETE option you can run later in case things got stuck the
> > first time around. I suppose we could do
On Thu, 29 Jun 2023, 14:45 Álvaro Herrera, wrote:
> ALTER TABLE DETACH CONCURRENTLY had to deal with this also, and it did it
> by having a COMPLETE option you can run later in case things got stuck the
> first time around. I suppose we could do something similar, where the
> server
ALTER TABLE DETACH CONCURRENTLY had to deal with this also, and it did it by
having a COMPLETE option you can run later in case things got stuck the first
time around. I suppose we could do something similar, where the server
automatically does the needful, whatever that is.
Andreas Karlsson 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
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
Hi,
It's documented that a failed REINDEX can leave behind a transient
index, and I'm not going to speculate on all the conditions that could
lead to this situation. However, cancelling a REINDEX CONCURRENTLY
will reliably leave behind the index it was building (_ccnew).
Doesn't a cancellation
