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
Date: 2018-07-14 10:39:56
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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

In response to


Browse pgsql-hackers by date

  From Date Subject
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