On 2013-05-17 10:45:26 +0300, Heikki Linnakangas wrote: > On 16.05.2013 04:15, Andres Freund wrote: > >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. > > You need an AccessExclusiveLock on the relation to make sure that after you > have checked that pages 10-15 are empty, and truncated them away, a backend > doesn't come along a few seconds later and try to read page 10 again. There > might be an old sequential scan in progress, for example, that thinks that > the pages are still there.
But that seems easily enough handled: We know the current page in its scan cannot be removed since its pinned. So make heapgettup()/heapgetpage() pass something like RBM_IFEXISTS to ReadBuffer and if the read fails recheck the length of the relation before throwing an error. There isn't much besides seqscans that can have that behaviour afaics: - (bitmap)indexscans et al. won't point to completely empty pages - there cannot be a concurrent vacuum since we have the appropriate locks - if a trigger or something else has a tid referencing a page there need to be unremovable tuples on it. The only thing that I immediately see are tidscans which should be handleable in a similar manner to seqscans. Sure, there are some callsites that need to be adapted but it still seems noticeably easier than what you proposed upthread. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
