Re: First-draft release notes for next week's releases
От | Alvaro Herrera |
---|---|
Тема | Re: First-draft release notes for next week's releases |
Дата | |
Msg-id | 20140317235130.GQ6899@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: First-draft release notes for next week's releases (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: First-draft release notes for next week's releases
Re: First-draft release notes for next week's releases |
Список | pgsql-hackers |
Andres Freund wrote: > 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()... Ugh :-( > 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. Isn't this what VACUUM FULL does? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: