Re: Proposal: Log inability to lock pages during vacuum - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Proposal: Log inability to lock pages during vacuum
Date
Msg-id 545C1A58.9050400@BlueTreble.com
Whole thread Raw
In response to Re: Proposal: Log inability to lock pages during vacuum  (Greg Stark <stark@mit.edu>)
Responses Re: Proposal: Log inability to lock pages during vacuum  (Andres Freund <andres@2ndquadrant.com>)
Re: Proposal: Log inability to lock pages during vacuum  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 11/6/14, 5:40 PM, Greg Stark wrote:
> On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> 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.

For some reason I don't have Andres' original email, so I'll reply here: I agree with you, and my original proposal was
simplyto log how many pages were skipped, but that was objected to. Simply logging this extra information would be a
patchof a dozen lines or less.
 

The problem right now is there's no way to actually obtain evidence that this is (or isn't) something to worry about,
becausewe just silently skip pages. If we had any kind of tracking on this we could stop guessing. :(
 

> I agree bloat isn't really a threat, but what about the relfrozenxid?
> If we skip even one page we don't get to advance it and retrying could
> eliminate those skipped pages and allow us to avoid a vacuum freeze
> which can be really painful. Of course that only works if you can be
> sure you haven't overflowed and forgotten any skipped pages and if you
> don't find the page still pinned every time until you eventually give
> up on it.

The overflow part shouldn't be that big a deal. Either we just bump the array size up some more, or worst-case we scan
itwhenever it fills (like we do when we fill vacrelstats->dead_tuples.
 

But like I said above, I think this is already making a mountain out of a mole-hill, until we have evidence there's a
realproblem.
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Proposal: Log inability to lock pages during vacuum
Next
From: Craig Ringer
Date:
Subject: Re: tracking commit timestamps