Re: 8.3.0 Core with concurrent vacuum fulls

Tom Lane wrote:
> The reason the critical section is so large is that we're manipulating
> the contents of a shared buffer, and we don't want a failure to leave a
> partially-modified page in the buffer. We could fix that if we were to
> memcpy the page into local storage and do all the pruning work there.
> Then the critical section would only surround copying the page back to
> the buffer and writing the WAL record. Copying the page is a tad
> annoying but heap_page_prune is an expensive operation anyway, and
> I think we really are at too much risk of PANIC the way it's being done
> now. Has anyone got a better idea?

We could do the pruning in two phases: first figure out what to do
without modifyng anything, outside critical-section, and then actually
do it, inside critical section.

Looking at heap_page_prune, we already collect information of what we
did in the redirected/nowdead/nowunused arrays for WAL logging purposes.
We could use that, but we would also have to teach heap_prune_chain to
not step into tuples that we've already decided to remove.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com