Re: Nasty btree deletion bug - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Nasty btree deletion bug
Date
Msg-id 21061.1161877649@sss.pgh.pa.us
Whole thread Raw
In response to Re: Nasty btree deletion bug  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Nasty btree deletion bug  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Re: Nasty btree deletion bug  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Heikki Linnakangas <heikki@enterprisedb.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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Nasty btree deletion bug
Next
From: Bruce Momjian
Date:
Subject: Re: Replication documentation addition