Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA25865; Wed, 21 Apr 93 12:34:37 -0700
Message-Id: <9304211934.AA25865@postgres.Berkeley.EDU>
From: Nat Howard <nrh@uunet.uu.net>
Subject: Re: incrementing counter
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of "Wed, 21 Apr 93 11:01:55 PDT."
             <9304211801.AA03165@faerie.CS.Berkeley.EDU> 
Date: Wed, 21 Apr 93 15:34:53 -0400
From: Nat Howard <nrh@uunet.uu.net>


Paul Aoki writes:

>Nat Howard <nrh@uunet.uu.net> 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

Interestingly, this works faster, but seems just as capable of causing
the "append" problem mentioned in my last note.

Try:

Q1				Q2

begin	
				begin

replace
retrieve
end
				replace
				retrieve
				end



You wind up with:

* retrieve(tt_number.oid, tt_number.all)\g

Query sent to backend is "retrieve(tt_number.oid, tt_number.all)"
-----------------------------
| oid         | tt_number   |
-----------------------------
| 151194      | 2           |
-----------------------------
| 151194      | 2           |
-----------------------------


The weird thing is that when Q2 asks the question, before the
second "end", it looks like this:

-----------------------------
| oid         | tt_number   |
-----------------------------
| 151194      | 1           |
-----------------------------
| 151194      | 2           |
-----------------------------

I admit bafflement (but plead ignorance -- this is my first
serious dip into postgres).

Is this really that hard?
