Re: Proposal: Log inability to lock pages during vacuum

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Proposal: Log inability to lock pages during vacuum
Дата
Msg-id 545C1A58.9050400@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Proposal: Log inability to lock pages during vacuum  (Greg Stark <stark@mit.edu>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Proposal: Log inability to lock pages during vacuum
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: tracking commit timestamps