Re: BUG #10315: Transactions seem to be releasing locks early?

On Wed, May 14, 2014 at 12:21 PM, Greg Stark <stark@mit.edu> wrote:
> On Tue, May 13, 2014 at 9:51 PM,  <tim.channell@gmail.com> wrote:
>> 7. Back in the second transaction, our DELETE has executed because the lock
>> was released. It would be expected to show "DELETE 1", because the first
>> transaction re-inserted the deleted record. But, it shows DELETE 0.
>
> It can't see the second row because it was inserted after the delete
> query started.
>
> I think in SERIALIZABLE mode it would be flagged as a serialization
> failure but I'm not sure.
Yep because session 1 has done a concurrent update on the row session
2 is trying to delete. You would actually get something like that:
=# DELETE FROM test WHERE id = 2;
ERROR:  40001: could not serialize access due to concurrent update
LOCATION:  ExecDelete, nodeModifyTable.c:447
--
Michael