Re: First-draft release notes for next week's releases
От | Andres Freund |
---|---|
Тема | Re: First-draft release notes for next week's releases |
Дата | |
Msg-id | 20140317233919.GS16438@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: First-draft release notes for next week's releases (Greg Stark <stark@mit.edu>) |
Ответы |
Re: First-draft release notes for next week's releases
Re: First-draft release notes for next week's releases |
Список | pgsql-hackers |
On 2014-03-17 21:09:10 +0000, Greg Stark wrote: > That said, it would be nice to actually fix the problem, not just > detect it. Eventually vacuum would fix the problem. I think. I'm not > really sure what will happen actually. Indexes will quite possibly stay corrupted. I think. If there was a index lookup for a affected row, the kill_prior_tuple logic will have quite possibly have zapped the index entry. Aside from that, it looks like VACUUM will have a hard time cleaning up as well. It looks to me like heap_prune_chain() won't remove tuples that are marked as both HeapTupleHeaderIsHeapOnly() and HeapTupleHeaderIsHotUpdated(), i.e. intermediate tuples in a HOT chain. Neither will lazy_scan_heap()... I think the best way to really cleanup a table is to use something like: ALTER TABLE rew ALTER COLUMN data TYPE text USING (data); where text is the previous type of the column. That should trigger a full table rewrite, without any finesse about tracking ctid chains. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: