Re: FSM corruption leading to errors

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: FSM corruption leading to errors
Дата
Msg-id CABOikdPC3bGk9x9qFEDBhgccqECOyNFxjo=gN9w247D-GoKb9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: FSM corruption leading to errors  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: FSM corruption leading to errors  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: FSM corruption leading to errors
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: FSM corruption leading to errors