From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Microvacuum for gist. |
Date: | 2015-09-17 16:44:36 |
Message-ID: | 55FAEDF4.4020609@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> But I don't understand this comment:
>
> + /*
> + * While we delete only one tuple at once we could mix calls
> + * PageIndexTupleDelete() here and PageIndexMultiDelete() in
> + * gistRedoPageUpdateRecord()
> + */
>
> Does this mean:
>
> Since we delete only one tuple per WAL record here, we can call
> PageIndexTupleDelete() here and re-play it with PageIndexMultiDelete() in
> gistRedoPageUpdateRecord()
yes. The problem was when we delete tuples with offset (2,4,6) with
PageIndexMultiDelete() we will delete exctly pointed tuples. Bur if we delete
tuple by PageIndexTupleDelete() with offset 2 then 4-th tuple will be moved 3 3
and 6 become 5. So, next tuple to delete now is 3 and we should call
PageIndexTupleDelete(3) and so on. And bug was: we deleted tuples in
ginpagevacuum with a help of PageIndexMultiDelete() and write to WAL his
argument, and recovery process uses PageIndexTupleDelete() without correcting
offset.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Shulgin, Oleksandr | 2015-09-17 16:47:42 | Re: On-demand running query plans using auto_explain and signals |
Previous Message | Jeff Janes | 2015-09-17 16:14:13 | Re: [PATCH] Microvacuum for gist. |