RE: Berkeley DB license

Поиск
Список
Период
Сортировка
От Michael A. Olson
Тема RE: Berkeley DB license
Дата
Msg-id 200005162116.OAA78742@triplerock.olsons.net
обсуждение исходный текст
Ответ на RE: Berkeley DB license  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Список pgsql-hackers
At 11:51 AM 5/16/00 -0700, Mikheev, Vadim wrote:

> > The issue was that SDB does two-phase locking, and I was asking if MVCC
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Due to this fact seems we'll have to change SDB anyway. With MVCC per-tuple
> locking is not needed. Short-term per-buffer _latches_ are used to prevent
> concurrent changes in a buffer, no locks made via lock manager.

The locking, logging, and buffer management interfaces are all available
independently.  Certainly it would be possible to modify the current
implementation to do System R-style shadow paging, or some other technique,
but to continue to use the current log manager to roll back or reapply
changes as necessary.

In that case, you'd take out the current 2PL lock acquisition calls during
a transaction, and add code to create shadow pages for updates.

Certainly the interfaces are there.  It'd be interesting to us if users
could select 2PL or MV for concurrency control on initialization, and
it appears on the face of it that that should be possible.

> I'm not sure does SDB API allow _any_ access to modified tuples or not.
> I would rather assume that it doesn't.

At present, Berkeley DB provides only 2PL.  We don't permit dirty reads,
but that's an implementation detail that would be fairly simple to change.
Berkeley DB does page-level, not record-level, locking.  There are short-
term mutex locks that protect shared structures.

My bet is that it would be better to use the lock manager, rather than
(say) spinlocks, to protect pages during updates; it's possible during
multi-page updates, like btree page splits.  Since the updating thread
may be descheduled during relatively long operations, you'd rather not
be holding a spinlock.  And you can acquire and release locks via lock
manager calls without trouble.

> MVCC and 2PL are quite different approaches to problem of concurrency
> control.

I'm joining the discussion quite late.  Can you summarize for me the
thinking behind adopting MVCC in place of 2PL?  Have you got performance
numbers for the two?
                mike



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Mikheev, Vadim"
Дата:
Сообщение: RE: Berkeley DB license
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Berkeley DB license