On Thu, Oct 20, 2016 at 11:34 AM, Michael Paquier <michael.paqu...@gmail.com > wrote:
> On Thu, Oct 20, 2016 at 2:50 PM, Pavan Deolasee > <pavan.deola...@gmail.com> wrote: > > Actually, if we could add an API which can truncate FSM to the given heap > > block, then the user may not even need to run VACUUM, which could be > costly > > for very large tables. > > FreeSpaceMapTruncateRel()? > Right. We need a SQL callable function to invoke that. > > > Also, AFAICS we will need to backport > > pg_truncate_visibility_map() to older releases because unless the VM is > > truncated along with the FSM, VACUUM may not scan all pages and the FSM > for > > those pages won't be recorded. > > This would need a careful lookup, and it would not be that complicated > to implement. And this bug justifies the presence of a tool like that > actually... But usually those don't get a backpatch, so the > probability of getting that backported is low IMO, personally I am not > sure I like that either. > Just to clarify, I meant if we truncate the entire FSM then we'll need API to truncate VM as well so that VACUUM rebuilds everything completely. OTOH if we provide a function just to truncate FSM to match the size of the table, then we don't need to rebuild the FSM. So that's probably a better way to handle FSM corruption, as far as this particular issue is concerned. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
