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
|
Список | 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 по дате отправления: