Re: Proposal: Log inability to lock pages during vacuum

On 10/21/14, 5:39 PM, Alvaro Herrera wrote:
> Jim Nasby wrote:
>
>> Currently, a non-freeze vacuum will punt on any page it can't get a
>> cleanup lock on, with no retry. Presumably this should be a rare
>> occurrence, but I think it's bad that we just assume that and won't
>> warn the user if something bad is going on.
>
> I think if you really want to attack this problem, rather than just
> being noisy about it, what you could do is to keep a record of which
> page numbers you had to skip, and then once you're done with your first
> scan you go back and retry the lock on the pages you skipped.

I'm OK with that if the community is; I was just trying for minimum invasiveness.

If I go this route, I'd like some input though...

- How to handle storing the blockIDs. Fixed size array or something fancier? What should we limit it to, especially since we're already allocating maintenance_work_mem for the tid array.

- What happens if we run out of space to remember skipped blocks? I could do something like what we do for running out of space in the dead_tuples array, but I'm worried that will add a serious amount of complexity, especially since re-processing these blocks could be what actually pushes us over the limit.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com