Message-Id: <9304221332.AA02036@postgres.Berkeley.EDU>
From: aoki@postgres.berkeley.edu (Paul M. Aoki)
Subject: Re: incrementing counter
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Thu, 22 Apr 93 05:15:52 -0700 
	     <9304221215.AA01779@postgres.Berkeley.EDU> 
Date: Thu, 22 Apr 93 06:32:22 -0700
Sender: aoki@postgres.Berkeley.EDU

> This is my solution as well ie. acquire `write locks' for all tables
> you may want to update at the start of any transaction.

and of course you should watch out for what jeff meredith pointed
out, which is the fact that my discussion of locking is only
loosely related to postgres reality and does not actually reflect 
all of its quirks :-)

> 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?

as someone kindly pointed out in private mail, sql allows one to
perform retrievals "for update," which seems reasonable.  i suppose 
this is all an artifact of the fact that in quel (university
ingres) the transaction unit was exactly one query statement :-)

suggestions for new, useful features may be directed to
	marc@postgres.berkeley.edu
:-)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki