| 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 |
| Message-ID: | 638aa9cf-4e28-a1a4-d2f3-b6697d7736cc@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| 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 |