On 2016-06-06 11:37:25 -0400, Robert Haas wrote: > On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
