Re: Brain dump: btree collapsing

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Brain dump: btree collapsing
Дата
Msg-id 9218.1045253937@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Brain dump: btree collapsing  ("Curtis Faith" <curtis@galtcapital.com>)
Ответы Re: Brain dump: btree collapsing
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: location of the configuration files
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: location of the configuration files