Re: GiST VACUUM
От | Heikki Linnakangas |
---|---|
Тема | Re: GiST VACUUM |
Дата | |
Msg-id | 638aa9cf-4e28-a1a4-d2f3-b6697d7736cc@iki.fi обсуждение исходный текст |
Ответ на | Re: GiST VACUUM (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: GiST VACUUM
|
Список | pgsql-hackers |
On 14/07/18 10:26, Andrey Borodin wrote: > This is tradeoff between complex concurrency feature and possibility > of few dead tuples left after VACUUM. I want to understand: is it > something dangerous in this dead tuples? Yeah, that's bad. When a new heap tuple is inserted in the same location, the old index tuple will point to the new, unrelated, tuple, and you will get incorrect query results. > There is one more serious race condition: result of first scan is > just a hint where to look for downlinks to empty pages. If internal > page splits between scan and cleanup, offsets of downlinks will be > changed, cleanup will lock pages, see non-empty pages and will not > delete them (though there are not dead tuples, just not deleted empty > leafs). That's fine. Leaving behind a few empty pages is harmless, the next vacuum will pick them up. - Heikki
В списке pgsql-hackers по дате отправления: