Re: Reviewing freeze map code

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Reviewing freeze map code
Дата
Msg-id 20160606202728.tomkrknleyvj5bbp@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Reviewing freeze map code  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Reviewing freeze map code  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2016-06-06 16:18:19 -0400, Stephen Frost wrote:
> That could be as simple as a query with the right things installed, or
> it might be an independent tool, but not having any way to check isn't
> good.  That said, trying to make VACUUM do that doesn't make sense to me
> either.

The point is that VACUUM *has* these types of checks. And had so for
many years:    else if (all_visible_according_to_vm && !PageIsAllVisible(page)             && VM_ALL_VISIBLE(onerel,
blkno,&vmbuffer))    {        elog(WARNING, "page is not marked all-visible but visibility map bit is set in relation
\"%s\"page %u",             relname, blkno);        visibilitymap_clear(onerel, blkno, vmbuffer);    }
...   else if (PageIsAllVisible(page) && has_dead_tuples)    {        elog(WARNING, "page containing dead tuples is
markedas all-visible in relation \"%s\" page %u",             relname, blkno);        PageClearAllVisible(page);
MarkBufferDirty(buf);       visibilitymap_clear(onerel, blkno, vmbuffer);    }
 

the point is that, after the introduction of the freeze bit, there's no
way to reach them anymore (and they're missing a useful extension of
these warnings, but ...); these warnings have caught bugs.  I don't
think it'd advocate for the vacuum option otherwise.


Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh berkus
Дата:
Сообщение: Re: [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Reviewing freeze map code