Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA02735; Thu, 22 Apr 93 08:56:47 -0700
Date: Thu, 22 Apr 93 08:56:47 -0700
Message-Id: <9304221556.AA02735@postgres.Berkeley.EDU>
From: jean@angrboda.css.gov (Jean Anderson)
Subject: Re: incrementing counter
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu

Paul M. Aoki <aoki@postgres.Berkeley.EDU>:
> as someone kindly pointed out in private mail, sql allows one to
> perform retrievals "for update," which seems reasonable.

Oracle allows a "select ... for update" which prohibits reads on the data.
Sybase's "select .... holdlock" does not prohibit reads; the strategy for 
blocking reads is to do an update that puts exclusive locks on the data.
Sybase System 10, coming out this summer, will be adding native cursors
that do "select ... for update".

Gerry Stringer <gerry@camscan.co.uk> writes:
> IMHO doing this sort of code requires too much knowledge and fudging.
> Perhaps an answer is to have an optional exclusive read lock (like a
> write lock) or manual control of locking?

I agree, but I hope folks realize that "knowledge and fudging" is required
for commercial databases; i.e., this is not a Postgres problem, it is a
concurrency management challenge.

Even when the fudging is reduced, it doesn't eliminate the need to know.
Oracle's "select ... for update" and other commands that let you manually
control locking are excellent capabilities -- and dangerous in the hands
of novice sql-ers, guaranteeing continued stressful employment for the 
DBA's who have to troubleshoot and make a complicated system work reliably.
To their credit, Oracle also provides a lock monitor which makes sleuthing
down lock problems easier.

 -jean