Re: possible concurrency bug or mistake in understanding read-committed behavior

Поиск
Список
Период
Сортировка
От Jignesh Shah
Тема Re: possible concurrency bug or mistake in understanding read-committed behavior
Дата
Msg-id AANLkTi=pmz_StyCGaDT-QsNd+5nTNYZUAm4PPn-twm6_@mail.gmail.com
обсуждение исходный текст
Ответ на possible concurrency bug or mistake in understanding read-committed behavior  (Jignesh Shah <jkshah@gmail.com>)
Ответы Re: possible concurrency bug or mistake in understanding read-committed behavior  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
Actually cutting down my mail to something more readable..

Lets consider two transactions

BEGIN;       BEGIN;
DELETE FROM sbtest WHERE id=500815;
INSERT INTO sbtest
values(500815,0,'','aaaaaaaaaaffffffffffrrrrrrrrrreeeeeeeeeeyyyyyyyyyy');       DELETE FROM sbtest WHERE id=500815;
        < ------- hangs/waits 
END;
COMMIT      DELETE 0 – returns success but doesn’t delete any rows . It
doesn't roll back the transaction     INSERT INTO sbtest
values(500815,0,'','aaaaaaaaaaffffffffffrrrrrrrrrreeeeeeeeeeyyyyyyyyyy');    ERROR: duplicate key value violates unique
constraint"sbtest_pkey"    END;    ROLLBACK 

The question is should the delete fail if it doesn't exist and cause a
rollback or succeed with DELETE 0 ?

The other way I tried is I tried doing the DELETE before insert in the
first one and same results.. So irrespective of how it does things if
DELETE starts before the first transaction commits, then the answer is
"ERROR: duplicate key"
What happening is while DELETE tries to delete the old row and INSERT
then tries to compete against the new row..
Not sure which way should be right in read-committed.
What’s the official READ-COMMITTED semantics for this?

Thanks.
Regards,
Jignesh


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Explain analyze getrusage tracking
Следующее
От: Robert Haas
Дата:
Сообщение: Re: unlogged tables