Re: GiST VACUUM

Поиск
Список
Период
Сортировка
Искать
От
Heikki Linnakangas
Тема
Re: GiST VACUUM
Дата
Msg-id
638aa9cf-4e28-a1a4-d2f3-b6697d7736cc@iki.fi
Ответ на
Re: GiST VACUUM (Andrey Borodin)
Список
Дерево обсуждения
GiST VACUUM Andrey Borodin <x4mmm@yandex-team.ru>
Re: GiST VACUUM Thomas Munro <thomas.munro@enterprisedb.com>
Re: GiST VACUUM Andrey Borodin <x4mmm@yandex-team.ru>
Re: GiST VACUUM Heikki Linnakangas <hlinnaka@iki.fi>
Re: GiST VACUUM Andrey Borodin <x4mmm@yandex-team.ru>
Re: GiST VACUUM Heikki Linnakangas <hlinnaka@iki.fi>
Re: GiST VACUUM Andrey Borodin <x4mmm@yandex-team.ru>
Re: GiST VACUUM Andrey Borodin <x4mmm@yandex-team.ru>
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 по дате отправления
От: Peter Eisentraut
Дата:
От: Peter Eisentraut
Дата:
FAQ