Skip site navigation (1) Skip section navigation (2)

Re: Think I see a btree vacuuming bug

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Think I see a btree vacuuming bug
Date: 2002-05-28 09:12:06
Message-ID: a9c6fuk166i5eonbsord827lhkhjbae9ee@4ax.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Zeugswetter Andreas SB SDDate: 2002-05-28 12:06:10
Subject: Re: SRF rescan testing
Previous:From: Henrik SteffenDate: 2002-05-28 07:53:58
Subject: Invalid length of startup packet - solved!

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group