On Thu, Dec 17, 2015 at 12:31 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
>> [orders.user_id references users.id]
> In your test case,
>
>> T1 T2
>> |-----------------------------|----------------------------------|
>> BEGIN ISOLATION LEVEL
>> REPEATABLE READ;
>>
>> UPDATE orders
>> SET name = 'order of foo',
>> user_id = 1
>> WHERE id = 1;
>>
>> BEGIN ISOLATION LEVEL
>> REPEATABLE READ;
>>
>> UPDATE users
>> SET date = now()
>> WHERE id = 1;
>>
>> COMMIT;
>>
>> UPDATE orders
>> SET name = 'order of foo (2)',
>> user_id = 1
>> WHERE id = 1;
>
> we have a transaction that takes a lock-only multi in table
> users, and then when we do the second update we don't look it up
> because ...??
The referencing column value did not change. (We would not have
looked up on the first update either, since it also didn't change
there.)
> And then this causes the test case not to fail because ..?
The concurrent update of the referencing table is not seen as a
write conflict (because it didn't actually change).
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
