Re: Reviewing freeze map code

On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2016-06-06 05:34:32 -0400, Robert Haas wrote:
>> On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> >> Attached is a sample patch that controls full page vacuum by new GUC parameter.
>> >
>> > Don't we want a reloption for that? Just wondering...
>>
>> Why? Just for consistency? I think the bigger question here is
>> whether we need to do anything at all. It's true that, without some
>> new option, we'll lose the ability to forcibly vacuum every page in
>> the relation, even if all-frozen. But there's not much use case for
>> that in the first place. It will be potentially helpful if it turns
>> out that we have a bug that sets the all-frozen bit on pages that are
>> not, in fact, all-frozen. Otherwise, what's the use?
>
> 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. 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. 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).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company