From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Log inability to lock pages during vacuum |
Date: | 2014-11-07 01:03:20 |
Message-ID: | 545C1A58.9050400@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/6/14, 5:40 PM, Greg Stark wrote:
> On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund <andres(at)2ndquadrant(dot)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 simply to log how many pages were skipped, but that was objected to. Simply logging this extra information would be a patch of 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, because we 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 it whenever 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 real problem.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2014-11-07 02:16:18 | Re: tracking commit timestamps |
Previous Message | Greg Stark | 2014-11-06 23:40:18 | Re: Proposal: Log inability to lock pages during vacuum |