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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
