Re: btree shrinking again - Mailing list pgsql-hackers

From Tom Lane
Subject Re: btree shrinking again
Date
Msg-id 1677.1037557523@sss.pgh.pa.us
Whole thread Raw
In response to btree shrinking again  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: btree shrinking again  ("Curtis Faith" <curtis@galtair.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@dcc.uchile.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_stat_database shows userid as OID
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] DECLARE CURSOR