RE: Berkeley DB license

From: "Michael A(dot) Olson" <mao(at)sleepycat(dot)com>
To: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
Cc: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: RE: Berkeley DB license
Date: 2000-05-16 21:14:13
Message-ID: 200005162116.OAA78742@triplerock.olsons.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-05-16 21:40:36 Re: type conversion discussion
Previous Message Hannu Krosing 2000-05-16 20:26:13 Re: Berkeley DB license