Re: Should I implement DROP INDEX CONCURRENTLY? - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Should I implement DROP INDEX CONCURRENTLY?
Date
Msg-id CA+U5nMJOBUOMFdSscKr1UZ6PZ0RDZo-=qjFeNnp98XMC6vAfZg@mail.gmail.com
Whole thread Raw
In response to Re: Should I implement DROP INDEX CONCURRENTLY?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should I implement DROP INDEX CONCURRENTLY?
Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)
List pgsql-hackers
On Tue, Jan 3, 2012 at 11:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jim Nasby <jim@nasby.net> writes:
>> On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
>>> This could well be related to the fact that DropRelFileNodeBuffers()
>>> does a scan of shared_buffers, which is an O(N) approach no matter the
>>> size of the index.
>
>> Couldn't we just leave the buffers alone? Once an index is dropped and that's pushed out through the catalog then
nothingshould be trying to access them and they'll eventually just get aged out. 
>
> No, we can't, because if they're still dirty then the bgwriter would
> first try to write them to the no-longer-existing storage file.  It's
> important that we kill the buffers immediately during relation drop.
>
> I'm still thinking that it might be sufficient to mark the buffers
> invalid and let the clock sweep find them, thereby eliminating the need
> for a freelist.

My patch puts things on the freelist only when it is free to do so.
Not having a freelist at all is probably a simpler way of avoiding the
lock contention, so I'll happily back that suggestion instead. Patch
attached, previous patch revoked.

> Simon is after a different solution involving getting
> rid of the clock sweep...

err, No, he isn't. Not sure where that came from since I'm advocating
only minor changes there to curb worst case behaviour.

But lets discuss that on the main freelist thread.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: 16-bit page checksums for 9.2
Next
From: Ants Aasma
Date:
Subject: Re: 16-bit page checksums for 9.2