Re: FSM corruption leading to errors

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: FSM corruption leading to errors
Дата
Msg-id CAB7nPqSk+-4dUBEapJz4bN7EXJ12vxOt980+--AO=kQ7+C3=1g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: FSM corruption leading to errors  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Ответы Re: FSM corruption leading to errors  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Список pgsql-hackers
On Thu, Oct 20, 2016 at 2:50 PM, Pavan Deolasee
<pavan.deolasee@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()?

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



В списке pgsql-hackers по дате отправления:

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