Re: Changing the transaction isolation level within the stored
От | Andrew Sullivan |
---|---|
Тема | Re: Changing the transaction isolation level within the stored |
Дата | |
Msg-id | 20060126113902.GB3995@phlogiston.dyndns.org обсуждение исходный текст |
Ответ на | Re: Changing the transaction isolation level within the stored (Markus Schaber <schabi@logix-tt.com>) |
Ответы |
Re: Changing the transaction isolation level within the stored
|
Список | pgsql-sql |
On Thu, Jan 26, 2006 at 10:42:54AM +0100, Markus Schaber wrote: > AFAIK, in PostgreSQL normal SQL commands cannot create deadlocks at all, > the only way to introduce deadlocks is to issue LOCK commands to take > locks manually. And for this rare case, PostgreSQL contains a deadlock > detection routine that will abort one of the insulting transactions, and > the others can proceed. You can too. Consider this: t1 t2 BEGIN; BEGIN; UPDATE table1 SET col1= UPDATE table2 SET col1= col1+5; (SELECT col3FROM DELETE FROM table2 WHERE table3);col1 = col1+6; UPDATE table1 SET col1 = col1 +5; COMMIT; COMMIT; Suppose these are concurrent. The problem here is that each transaction need something in the other transaction either to complete or rollback before the work can proceed. So one of them has to lose. A -- Andrew Sullivan | ajs@crankycanuck.ca This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie
В списке pgsql-sql по дате отправления: