On 2014-11-06 14:55:37 -0600, Jim Nasby wrote:
> On 10/29/14, 11:49 AM, Jim Nasby wrote:
> >On 10/21/14, 6:05 PM, Tom Lane wrote:
> >>Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> >>>- What happens if we run out of space to remember skipped blocks?
> >>
> >>You forget some, and are no worse off than today. (This might be an
> >>event worthy of logging, if the array is large enough that we don't
> >>expect it to happen often ...)
> >
> >Makes sense. I'll see if there's some reasonable way to retry pages when the array fills up.
> >
> >I'll make the array 2k in size; that allows for 512 pages without spending a bunch of memory.
>
> Attached is a patch for this. It also adds logging of unobtainable cleanup locks, and refactors scanning a page for
vacuuminto it's own function.
>
> Anyone reviewing this might want to look at
https://github.com/decibel/postgres/commit/69ab22f703d577cbb3d8036e4e42563977bcf74b,which is the refactor with no
whitespacechanges.
>
> I've verified this works correctly by connecting to a backend with gdb and halting it with a page pinned. Both vacuum
andvacuum freeze on that table do what's expected, but I also get this waring (which AFAICT is a false positive):
I think the retry logical is a largely pointless complication of already
complex enough code. You're fixing a problem for which there is
absolutely no evidence of its existance. Yes, this happens
occasionally. But it's going to be so absolutely minor in comparison to
just about every other source of bloat.
So, I pretty strongly against retrying. I could live with adding logging
of the number of pages skipped due to not being able to acquire the
cleanup lock. I don't think that's going to do help many people, but the
cost is pretty low.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
