Re: Brain dump: btree collapsing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Brain dump: btree collapsing
Date
Msg-id 9218.1045253937@sss.pgh.pa.us
Whole thread Raw
In response to Re: Brain dump: btree collapsing  ("Curtis Faith" <curtis@galtcapital.com>)
Responses Re: Brain dump: btree collapsing
List pgsql-hackers
"Curtis Faith" <curtis@galtcapital.com> writes:
> 4) This could easily be reordered into:

>       buf = ReadBuffer(rel, blkno);            /* pin next page
> */
>       LockBuffer(buf, BUFFER_LOCK_UNLOCK);    /* release lock on
> current page */
>     LockBuffer(buf, BT_READ);                 /* lock next page */
>       ReleaseBuffer(buf);                       /* now release pin on
> previously current page */

>    without affecting the logic of the code or causing any deadlock
> problems since the release still occurs before the lock of the next
> page.

Sorry, that *does* create deadlocks.  Remember the deletion process is
going to need superexclusive lock (not only a BT_WRITE buffer lock,
but no concurrent pins) in order to be sure there are no scans stopped
on the page it wants to delete.  (In the above pseudocode, the fact that
you still hold a pin on the previously-current page makes you look
exactly like someone who's in the middle of scanning that page, rather
than trying to leave it.)  The same would be true of both pages
if it's trying to merge.

> 5) A mutex/spinlock that was stored in the index could be acquired by
> the scan code like this:

"Stored in the index"?  And how will you do that portably?  But it
doesn't matter, because the approach deadlocks.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: location of the configuration files
Next
From: Bruce Momjian
Date:
Subject: Re: location of the configuration files