Re: slow dropping of tables, DropRelFileNodeBuffers, tas

On 7 June 2012 17:34, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> On 7 June 2012 14:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Say what?  That's a performance result and proves not a damn thing about
>>> safety.
>
>> Of course not.
>
>> Based on the rationale explained in the code comments in the patch, it
>> seems like a reasonable thing to me now.
>
>> The argument was that since we hold AccessExclusiveLock on the
>> relation, no other agent can be reading in new parts of the table into
>> new buffers, so the only change to a buffer would be away from the
>> dropping relation, in which case we wouldn't care. Which seems correct
>> to me.
>
> Oh, I must be confused about which patch we are talking about --- I
> thought this was in reference to some of the WIP ideas that were being
> thrown about with respect to using lock-free access primitives.  Which
> patch are you proposing for commit now, exactly?

Both of these, as attached up thread.

Simon's patch - dropallforks.v1.patch
Jeff's patch - DropRelFileNodeBuffers_unlock_v1.patch
(needs a little tidyup)

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