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
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 - ? |