Subject: Re: incrementing counter

From: Gerry Stringer <[email-masked]>
Date: Thu, 22 Apr 93 05:15:52 -0700

Nat Howard <[email-masked]> writes:,
> What I *really* want, though, is a way get atomically-incremented 
> values, so that neither transaction must time out:

>>this seems to work better:

>>begin
>>replace tt_number (tt_number = tt_number.tt_number + 1)
>>retrieve (tt_number.tt_number)
>>/* other stuff */
>>end
>> ...
>> ...

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

This is very artificial however, suppose you want to do an update
conditionally on values you read from a table - you end up needing to
do a dummy write to the table to lock it. Of course, this assumes that
you know the granularity of locking is the whole table.

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?

	gerry

+--------------------------------+---------------------------------+
|Gerry Stringer                  |Phone: +44 954 780926            |
|Cambridge Scanning Company Ltd  |Fax:   +44 954 789829            |
|Saxon Way                       |UUCP : [email-masked]       |
|Bar Hill                        |       [email-masked]        |
|Cambridge CB3 8SL               |       			   |
|United Kingdom                  |                                 |
+--------------------------------+---------------------------------+

---

From: [email-masked] (Paul M. Aoki)
Date: Thu, 22 Apr 93 06:32:22 -0700

> 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 :-)

> 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
	[email-masked]
:-)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki