Re: Heap truncation without AccessExclusiveLock (9.4)

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Heap truncation without AccessExclusiveLock (9.4)
Дата
Msg-id 20130516011510.GC22783@awork2.anarazel.de
обсуждение исходный текст
Ответ на Heap truncation without AccessExclusiveLock (9.4)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: Heap truncation without AccessExclusiveLock (9.4)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Extent Locks
Следующее
От: Jon Nelson
Дата:
Сообщение: Re: fallocate / posix_fallocate for new WAL file creation (etc...)