|From:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>|
|To:||Andrey Borodin <x4mmm(at)yandex-team(dot)ru>|
|Cc:||Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Костя Кузнецов <chapaev28(at)ya(dot)ru>|
|Subject:||Re: GiST VACUUM|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
That's fine. Leaving behind a few empty pages is harmless, the next
vacuum will pick them up.
|Next Message||Peter Eisentraut||2018-07-14 10:57:16||Re: make installcheck-world in a clean environment|
|Previous Message||Peter Eisentraut||2018-07-14 10:20:05||Re: psql \df option for procedures|