On 2016-06-06 11:37:25 -0400, Robert Haas wrote:
> On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund <andres@anarazel.de> wrote:
> > Except that we right now don't have any realistic way to figure out
> > whether this new feature actually does the right thing. Which makes
> > testing this *considerably* harder than just VACUUM (dwim). I think it's
> > unacceptable to release this feature without a way that'll tell that it
> > so far has/has not corrupted the database. Would that, in a perfect
> > world, be vacuum? No, probably not. But since we're not in a perfect world...
>
> I just don't see how running VACUUM on the all-frozen pages is going
> to help.
Because we can tell people in the beta2 announcement or some wiki page
"please run VACUUM(scan_all)" and check whether it emits WARNINGs. And
if we suspect freeze map in bug reports, we can just ask reporters to
run a VACUUM (scan_all).
> In terms of diagnostic tools, you can get the VM bits and
> page-level bits using the pg_visibility extension; I wrote it
> precisely because of concerns like the ones you raise here. If you
> want to cross-check the page-level bits against the tuple-level bits,
> you can do that with the pageinspect extension. And if you do those
> things, you can actually find out whether stuff is broken.
That's WAY out ouf reach of any "normal users". Adding a vacuum option
is doable, writing complex queries is not.
> Vacuuming the all-frozen pages won't tell you that. It will either do
> nothing (which doesn't tell you that things are OK) or it will change
> something (possibly without reporting any message, and possibly making
> a bad situation worse instead of better).
We found a number of bugs for the equivalent issues in all-visible
handling via the vacuum error reporting around those.
Greetings,
Andres Freund