Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CAD21AoDv1pV=yPNukrTWEOZ=COPSMwsJNCOXuu9MQAL0kgR4Gw@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Freeze avoidance of very large table.
List pgsql-hackers
On Thu, Aug 20, 2015 at 11:46 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Jim Nasby wrote:
>
>> I think things like pageinspect are very different; I really can't see any
>> use for those beyond debugging (and debugging by an expert at that).
>
> I don't think that necessarily means it must continue to be in contrib.
> Quite the contrary, I think it is a tool critical enough that it should
> not be relegated to be a second-class citizen as it is now (let's face
> it, being in contrib *is* second-class citizenship).
>

Attached patch is latest patch.
The how to do the VM regression test is changed so that we do test
without diagnostic functions.
In current patch, we do VACUUM and VACUUM FREEZE table, and check its
value of pg_class.relallvisible and relallfrozen.
When doing first VACUUM in regression test, the table doesn't have VM.
So VACUUM scans all pages and update exactly information about the
number of all-visible bit.
And when doing second VACUUM FREEZE, VACUUM FREEZE also scans all
pages because every page is not marked as all-frozen. So VACUUM FREEZE
can update exactly information about the number of all-frozen bit.

In previous patch, we checked a bit of VM one by one using by
diagnostic function, and compared between these result and
pg_class.relallvisible(/frozen).
So the essential check process is same as previous patch.
We can ensure correctness by using such procedure.

Regards,

--
Masahiko Sawada

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 9.4 broken on alpha
Next
From: Andres Freund
Date:
Subject: Re: 9.4 broken on alpha