| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Should I implement DROP INDEX CONCURRENTLY? |
| Date: | 2011-12-31 13:26:25 |
| Message-ID: | CA+U5nMLQjFQvgyDVZ7wH7EcGM7bZRoLngJSp7aOFXko0-7Ab9g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 30, 2011 at 10:20 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On ons, 2011-08-24 at 11:24 -0700, Daniel Farina wrote:
>> I was poking around at tablecmds and index.c and wonder if a similar
>> two-pass approach as used by CREATE INDEX CONCURRENTLY can be used to
>> create a DROP INDEX CONCURRENTLY, and if there would be any interest
>> in accepting such a patch.
>
> Hmm, it seems I just independently came up with this same concept. My
> problem is that if a CREATE INDEX CONCURRENTLY fails, you need an
> exclusive lock on the table just to clean that up. If the table is
> under constant load, you can't easily do that. So a two-pass DROP INDEX
> CONCURRENTLY might have been helpful for me.
Here's a patch for this. Please review.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| drop_index_concurrently.v1.patch | text/x-patch | 21.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2011-12-31 13:34:03 | pgsql: Send new protocol keepalive messages to standby servers. |
| Previous Message | Peter Eisentraut | 2011-12-30 22:20:20 | Re: Should I implement DROP INDEX CONCURRENTLY? |