RE: Berkeley DB license - Mailing list pgsql-hackers

From Michael A. Olson
Subject RE: Berkeley DB license
Date
Msg-id 200005162116.OAA78742@triplerock.olsons.net
Whole thread Raw
In response to RE: Berkeley DB license  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List 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 by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: RE: Berkeley DB license
Next
From: Hannu Krosing
Date:
Subject: Re: Berkeley DB license