Re: btree shrinking again

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: btree shrinking again
Date: 2002-11-17 18:25:23
Message-ID: 1677.1037557523@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> + Deletions are handled by getting a super-exclusive lock on the target
> page, so that no other backend has a pin on the page when the deletion
> starts. This means no scan is pointing at the page. This is OK for
> deleting leaf items, probably not OK for deleting internal nodes;
> will need to think harder when it's time to support index compaction.

> In what cases is not OK to delete an item from an internal node, holding
> a super-exclusive lock?

I believe the thing I was worried about when I wrote that note was the
stack of ancestor pointers maintained by an insert operation: the insert
will not have pins on those pages, but might try to return to them
later (to service a page split).

A simple-minded solution might be to keep the pins until the insert is
done, but you'd have to think about possible deadlock conditions as well
as loss of concurrency. I'd prefer to find a solution that didn't
require that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-11-17 19:33:05 Re: [GENERAL] DECLARE CURSOR
Previous Message Tom Lane 2002-11-17 18:16:29 Re: pg_stat_database shows userid as OID