Re: Think I see a btree vacuuming bug

On Mon, 27 May 2002 13:48:43 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
>> On leaf pages order index tuples by heap item pointer, if otherwise
>> equal. [blah, blah, ...]
>
>Doesn't help, I fear. Finding your place again is only one part
>of the problem. The other part is being sure that VACUUM won't delete
>the heap tuple before you get to it.

Ok, throwing away this one.

Another idea: As far as I understand, the problem arises from
"recent" page splits. Let's store a transaction id in each leaf page.
On a page split the currently highest active xid (*not* the backend's
current xid) is stored into the new right page. btbulkdelete has a
notion of "old" and "young" pages: If the page xid is less than the
oldest active transaction, then the index page is considered old,
otherwise young.

"Old" pages can savely be treated like up to yesterday: get a "super
exclusive" lock just on this page, do the changes, release the lock.

Whenever btbulkdelete is about to change a "young" index page, it has
to get "super exclusive" locks on all pages from the last preceding
"old" page (*) up to the current page. It does not have to hold all
these locks at the same time, it just has to get the locks in
"non-overtaking" mode.

To avoid deadlocks it might be necessary to release the read lock held
on the current page, while approaching it with "super exclusive" locks
from the left. Then the current page has to be rescanned.

(*) or the page following the last page we already had a "super
exclusive" lock on

Servus
Manfred