Re: possible concurrency bug or mistake in understanding read-committed behavior - Mailing list pgsql-hackers

From Jignesh Shah
Subject Re: possible concurrency bug or mistake in understanding read-committed behavior
Date
Msg-id AANLkTi=pmz_StyCGaDT-QsNd+5nTNYZUAm4PPn-twm6_@mail.gmail.com
Whole thread Raw
In response to possible concurrency bug or mistake in understanding read-committed behavior  (Jignesh Shah <jkshah@gmail.com>)
Responses Re: possible concurrency bug or mistake in understanding read-committed behavior
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Explain analyze getrusage tracking
Next
From: Robert Haas
Date:
Subject: Re: unlogged tables