Message-Id: <9304211923.AA25728@postgres.Berkeley.EDU>
From: aoki@postgres.berkeley.edu (Paul M. Aoki)
Subject: Re: bug in begin/end? replace?
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Wed, 21 Apr 93 14:35:56 -0400 
	     <9304211835.AA25328@postgres.Berkeley.EDU> 
Date: Wed, 21 Apr 93 12:24:14 -0700
Sender: aoki@postgres.Berkeley.EDU

> NOTICE:Apr 21 11:56:23:Timeout -- possible deadlock
> WARN:Apr 21 11:56:23:WaitOnLock: error on wakeup - Aborting this transaction

right.  this is one approach to a standard locking/transaction problem.
given that timeout is done rather than deadlock prevention or more
complicated deadlock detection, this is what you would expect, modulo the 
fact that for me, the "long pause" happens when you start the replace 
statements (for the reasons i described in my last message) rather than
the end statements.

> Here's the bug:
> Q1					Q2
> begin\g
> 					begin\g
>  retrieve (tt_number.tt_number)\g
> (gets "2")
> replace tt_number (tt_number=3)\g
> end\g
> 					retrieve (tt_number.tt_number)\g
> 					(gets "2")
> 					replace tt_number (tt_number=3)\g
> 					end\g

for me, the retrieve in Q2 gets 3.  which is not to say that there
isn't a bug, but that it's not a consistent one.

there are some known bugs (known in the sense that it is known that
there is a bug, the exact nature and fix have not been determined)
in the handling of dirty buffers.  i have a feeling this might be
related to them.
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki