Re: Reviewing freeze map code - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Reviewing freeze map code
Date
Msg-id 20160606202728.tomkrknleyvj5bbp@alap3.anarazel.de
Whole thread Raw
In response to Re: Reviewing freeze map code  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Reviewing freeze map code  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Josh berkus
Date:
Subject: Re: [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all
Next
From: Robert Haas
Date:
Subject: Re: Reviewing freeze map code