Re: Proposal: Log inability to lock pages during vacuum

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

In response to

Responses

Browse pgsql-hackers by date

  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