Skip site navigation (1) Skip section navigation (2)


From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Should I implement DROP INDEX CONCURRENTLY?
Date: 2012-01-16 16:17:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Dec 31, 2011 at 8:26 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> 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.

I don't see how setting indisvalid to false helps with this, because
IIUC when a session sees indisvalid = false, it is supposed to avoid
using the index for queries but still make new index entries when a
write operation happens - but to drop an index, I think you'd need to
get into a state where no one was using the index for anything at all.

Maybe we need to change indisvalid to a "char" and make it three
valued: c = being created currently, v = valid, d = being dropped
concurrently, or something like that.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-01-16 16:17:35
Subject: Re: New replication mode: write
Previous:From: Alvaro HerreraDate: 2012-01-16 16:01:50
Subject: Re: pgstat documentation tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group