Re: Heap truncation without AccessExclusiveLock (9.4) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Heap truncation without AccessExclusiveLock (9.4)
Date
Msg-id 20130516011510.GC22783@awork2.anarazel.de
Whole thread Raw
In response to Heap truncation without AccessExclusiveLock (9.4)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Heap truncation without AccessExclusiveLock (9.4)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On 2013-05-15 18:35:35 +0300, Heikki Linnakangas wrote:
> Truncating a heap at the end of vacuum, to release unused space back to
> the OS, currently requires taking an AccessExclusiveLock. Although it's only
> held for a short duration, it can be enough to cause a hiccup in query
> processing while it's held. Also, if there is a continuous stream of queries
> on the table, autovacuum never succeeds in acquiring the lock, and thus the
> table never gets truncated.
> 
> I'd like to eliminate the need for AccessExclusiveLock while truncating.

Couldn't we "just" take the extension lock and then walk backwards from
the rechecked end of relation ConditionalLockBufferForCleanup() the
buffers?
For every such locked page we check whether its still empty. If we find
a page that we couldn't lock, isn't empty or we already locked a
sufficient number of pages we truncate.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Extent Locks
Next
From: Jon Nelson
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)