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
|
Список | 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 по дате отправления: