Subject: locking in postgres 4.1

From: Joergen Haegg <[email-masked]>
Date: Tue, 09 Nov 1993 13:13:04 MET

This may be a FAQ but can anyone explain this to me?

What should I do to make sure not to corrupt data when several processes
updates the same class?

I tried to use begin/end. Problem is that I get the old data when the
lock releases. And no indication of this at 'end'.

I try to do like this:

Process A:
spog > begin
BEGIN successful

Process B:
spog > begin
BEGIN successful

Process A:
spog > retrieve (testa2.all)
 23           49          
 323          849         
 444          8383        
 444          8383        
spog > replace testa2(nn=11111) where testa2.u = "323"
REPLACE successful

Process B:
spog > retrieve (testa2.all)
 23           49          
 444          8383        
 444          8383        
 323          11111
spog > retrieve (testa2.all)
NOTICE:Nov  9 13:08:35:Timeout -- possible deadlock
WARN:Nov  9 13:08:35:WaitOnLock: error on wakeup - Aborting this transaction

???
Why this?

I would want process B to hang until process A executes 'end', and
then the data should be updated when B reads it.

Why can't I do this?

--------
Joergen Haegg				[email-masked]
System manager @ efd			Phone: international +46 46 107492
Lund Institute of Technology		Snailmail: DDG, Maildelivery 7, BOX 118
Fax: +46 46 104013			S-221 00 LUND, Sweden

"I wish there was a knob on the TV to turn up the intelligence.
There's a knob called `brightness', but it doesn't work."
		-- Gallagher

---

From: [email-masked] (Paul M. Aoki)
Date: Wed, 10 Nov 93 09:55:31 -0800

Joergen Haegg <[email-masked]> writes:
> spog > replace testa2(nn=3D11111) where testa2.u =3D "323"
> REPLACE successful
> Process B:
> WARN:Nov  9 13:08:35:WaitOnLock: error on wakeup - Aborting this transacti=

if the A replace happens before the B retrieves, the B retrieves should 
hang until A commits.  if the A replace happens after the B retrieves,
A should hang until B commits.  try it again and see if this is not
the case.  if not, send mail to bug-postgres.
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki