Re: FSM corruption leading to errors - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: FSM corruption leading to errors
Date
Msg-id CABOikdPC3bGk9x9qFEDBhgccqECOyNFxjo=gN9w247D-GoKb9g@mail.gmail.com
Whole thread Raw
In response to Re: FSM corruption leading to errors  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: FSM corruption leading to errors
List pgsql-hackers


On Thu, Oct 20, 2016 at 10:50 AM, Michael Paquier <michael.paquier@gmail.com> wrote:

 For VMs a good way would
be to use pg_visibility's pg_truncate_visibility_map(), but only for
9.6~.

Ah ok.. 
 
For FSM there is no real solution, and actually a
pg_truncate_fsm would prove to be useful here.

Right, that's what I proposed as an alternate idea. I agree this is much cleaner and less error prone approach.

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. 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. 

Thanks,
Pavan

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: FSM corruption leading to errors
Next
From: Michael Paquier
Date:
Subject: Re: FSM corruption leading to errors