From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Documentation fixes for pg_visibility |
Date: | 2016-06-27 22:05:41 |
Message-ID: | CA+TgmoY0SsPvPUWVPc1p1_yn1QDktmdTK7KJwbsNxTDtoyhTrA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 27, 2016 at 5:56 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
>> Under what circumstances would you wish to check only one page of a relation?
>
> What I'd like to be able to do is to stop scanning the relation once
> one defective tuple has been found: if there is at least one problem,
> the whole vm needs to be rebuilt anyway. So this function could be
> wrapped in a plpgsql function for example. It is more flexible than
> directly modifying this function so as it stops at the first problem
> stopped.
I think most likely the best way to handle this is teach VACUUM to do
PageClearAllVisible() and visibilitymap_clear() on any page where
VM_ALL_FROZEN(onerel, blkno, &vmbuffer) && !all_frozen. This would go
well with the existing code to clear incorrectly-set visibility map
bits, and it would allow VACUUM (DISABLE_PAGE_SKIPPING) to serve the
purpose you're talking about here, but more efficiently.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-06-27 23:59:46 | Re: How to kill a Background worker and Its metadata |
Previous Message | Tom Lane | 2016-06-27 22:04:23 | Re: fixing consider_parallel for upper planner rels |