agora inbox for postgres@postgres.berkeley.edu
help / color / mirror / Atom feedRe: locking [was: Use by a Business]
2+ messages / 2 participants
[nested] [flat]
* locking [was: Use by a Business]
@ 1994-05-31 02:53 Paul M. Aoki <aoki@postgres.Berkeley.EDU>
1994-05-31 01:55 ` Re: locking [was: Use by a Business] Mark Metson <gpurdy@fox.nstn.ns.ca>
0 siblings, 1 reply; 2+ messages in thread
From: Paul M. Aoki @ 1994-05-31 02:53 UTC (permalink / raw)
To: Michael Ubell <michael@montage.com>; +Cc: Mark Metson <gpurdy@fox.nstn.ns.ca>; legacy
Michael Ubell <michael@montage.com> writes:
> > it does do page-level locking for b-trees but not for r-trees and heaps.
> Doing page locking on b-trees but not on the underlying heap does not really
> buy you anything since if you do an update the whole heap table is locked so
> things will be single threaded no matter what you do in the b-tree.
well, yes. to quote src/doc/implementation/am.me, written by mike
olson (now at montage):
Users of the access method interface routines need not
worry about locking. The access method routines acquire
(and, when appropriate, release) locks on relations in
response to scans and updates. Heap relations are protected
by two-phase relation level locks. Btree indices use
Lehman-Yao5 short-term locking for high concurrency, but
since the underlying relations are locked at the relation
level, index updates are serialized. Rtree indices use two-
phase relation-level locking.
5 Lehman, P., Yao, S., ``Efficient Locking for Concurrent
Operations on B-trees'', ACM Transactions on Database Sys-
tems, 6(4), December 1981.
but having working b-link trees reduces the amount of work some
hypothetical person would have to do to convert the core system to
page-level locking.
(not that the last two messages have had anything to do with what
the guy was asking..)
--
Paul M. Aoki | CS Div., Dept. of EECS, UCB | aoki@postgres.Berkeley.EDU
| Berkeley, CA 94720 | ...!uunet!ucbvax!aoki
==============================================================================
To add/remove yourself to/from the POSTGRES mailing list: send mail with
the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"
If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
a human will deal with it. DO NOT post to the "postgres" mailing list.
==============================================================================
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: locking [was: Use by a Business]
1994-05-31 02:53 locking [was: Use by a Business] Paul M. Aoki <aoki@postgres.Berkeley.EDU>
@ 1994-05-31 01:55 ` Mark Metson <gpurdy@fox.nstn.ns.ca>
0 siblings, 0 replies; 2+ messages in thread
From: Mark Metson @ 1994-05-31 01:55 UTC (permalink / raw)
To: Paul M. Aoki <aoki@postgres.Berkeley.EDU>; +Cc: Michael Ubell <michael@montage.com>; legacy
On Mon, 30 May 1994, Paul M. Aoki wrote:
> Michael Ubell <michael@montage.com> writes:
...
> (not that the last two messages have had anything to do with what
> the guy was asking..)
...
Ah but they do, they do. Locking is the crux of the problem. I have a
complete application running at a Collection Agency in Business Basic
under SCO Unix System V. Standard code developed across a number of
employers in which when you edit a masterfile record the record is locked
using an 'EXTRACT' until unlocked using a READ or WRITE. Meanwhile it
sits on user's screen over lunch or until per-input timeouts realise
they've gone to lunch. There are two pricetags, $2500 and $2300, one for
new unix, one for new BASIC (can never recall which is which), total
$4800, which come up every time they think about computerising another
branch office. Assuming they have $4800 on hand, we'd all feel better if
they spent it on something more constructive, like buying hardware or
paying me. I wanted GNU instead of UNIX in the first place, but it wasnt
available back then. Now, the free unix I kept telling them was on the
horizon is here, we want to move to it. We also would like to move from
the BASIC if it'd be cheaper to rewrite than to buy a copy per possible
new site, and may HAVE to move from BASIC if we cannot get Business Basic
for Linux. I have just this day discovered some ALPHA code for running
SCO SysV executables under Linux, so possibly I might be able to stay
with BASIC, but if not, postgres is the only thing I've seen that might
be useable in its place, other than to take some standard ISAM code and
write a shared-memory record-locks-table or somesuch for it; and since
Linux kernel support for arbitrary locks has no
deadlock-detection/protection in it, I am rather wary of potential
deadlock situations if I try to add a key with one task while deleting a
key with another task in the same index; I suspect record-level locks on
the blocks ofa Btree would be in real deadlock danger in such scenarios.
I guess Business Basic spoiled me, I had never spent much thought on what
nifty tricks the language was taking care of for me in its
innocent-seeming record handling system.
Blessed Be. -MarkM-
==============================================================================
To add/remove yourself to/from the POSTGRES mailing list: send mail with
the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU"
If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
a human will deal with it. DO NOT post to the "postgres" mailing list.
==============================================================================
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~1994-05-31 02:53 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1994-05-31 02:53 locking [was: Use by a Business] Paul M. Aoki <aoki@postgres.Berkeley.EDU>
1994-05-31 01:55 ` Mark Metson <gpurdy@fox.nstn.ns.ca>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox