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

From: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andreas Karlsson" <andreas(at)proxel(dot)se>
Cc: "Thom Brown" <thom(at)linux(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?
Date: 2023-06-29 13:45:16
Message-ID: efaa44f0-fe56-4fdd-be68-f0272e896af9@app.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2023-06-29 14:12:54 plan_create_index_workers doesn't account for TOAST
Previous Message Tristan Partin 2023-06-29 13:15:35 Re: Meson build updates