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
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 |