Re: [HACKERS] ERROR: WaitOnLock: error on wakeup - Aborting this transaction

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: Vadim Mikheev <vadim(at)krs(dot)ru>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] ERROR: WaitOnLock: error on wakeup - Aborting this transaction
Date: 1999-05-23 14:44:00
Message-ID: 199905231444.XAA00795@ext16.sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > I get above message from the backend while trying to update same raw
> > from different transactions (I guess). Is this normal?
>
> 1=>begin;
> 2=>begin;
> 1=>update t set a = 1 where c = 1;
> 2=>update t set a = 1 where c = 2;
> 1=>update t set a = 2 where c = 2; -- blocked by 2
> 2=>update t set a = 2 where c = 1; --> deadlock

My sessions look like:

begin;
update t set a = 1 where c = 1;
select * from t where c = 1;
end;

So I think there is no possibility of a deadlock. Note that the error
happens with relatively large number of concurrent transactions
running. I don't see the error at # of transactions = 1~32 while I get
errors at 63 (I didn't try 33~62). In each session which raw gets
updated is decided by a random generator, so increasing # of
transactions might also increases the chance of conflicts, or 63 might
hit some threshold of certain resources, I don't know. The interesting
thing is the error never happen if I set the transaction isolation
mode to "serializable."

If I have time, I would do more test cases.
---
Tatsuo Ishii

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-05-23 16:32:01 Re: [HACKERS] DEFAULT fixed
Previous Message Vadim Mikheev 1999-05-23 12:04:16 createlang - ?