From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Nasty btree deletion bug |
Date: | 2006-10-26 15:47:29 |
Message-ID: | 21061.1161877649@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> I don't understand how this "in the meantime" thing works. I tried to
> work out a step-by-step example, could you take a look at it? See
> http://users.tkk.fi/~hlinnaka/pgsql/btree-deletion-bug/
[ looks at that for a bit... ] Yeah, you're right. Once the deletion
is completed, the F lower-bound key will disappear from the grandparent,
which would restore consistency --- but we could have already delivered
wrong search answers, so that won't do.
In theory, given a slow-enough-moving VACUUM process, this could happen
even without a crash. So I think that means we have to go over to the
other plan of locking everything all the way up to the top of the
deletion before we start doing it --- and also, we'll need crash
recovery logic to complete the incomplete deletion, same as for
incomplete inserts. Yech --- more code than I was hoping to have to
write, and more concurrency hit too.
OTOH we might be able to get rid of the notion of "half dead", which
would allow some simplifications.
Thanks for taking a close look!
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-10-26 15:53:09 | Re: [HACKERS] Replication documentation addition |
Previous Message | Heikki Linnakangas | 2006-10-26 15:00:15 | Re: Nasty btree deletion bug |