| From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Nasty btree deletion bug |
| Date: | 2006-10-26 17:08:10 |
| Message-ID: | 4540EB7A.2080201@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> On further reflection, I think I understand why we've not realized the
> existence of this bug before: in fact, it *doesn't* lead to wrong search
> answers. I think the only visible consequence is exactly the "failed to
> re-find parent key" VACUUM error that Ed saw. The reason is that the
> key misordering in the grandparent level is nearly harmless. Using your
> example of
Yep. It's pretty harmless.
But now that I look at the original post by Ed, I don't see how the
"failed to re-find parent key" error could result from the issue we've
been talking about. The error message is printed when _bt_getstackbuf is
unable to re-find an item in the parent of a deleted page, but
_bt_getstackbuf doesn't look at or compare the keys at all.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-10-26 17:21:53 | Re: Nasty btree deletion bug |
| Previous Message | Richard Troy | 2006-10-26 17:07:05 | Re: Replication documentation addition |