Re: Nasty btree deletion bug

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

In response to

Responses

Browse pgsql-hackers by date

  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