Re: BUG #13681: Serialization failures caused by new multixact code of 9.3 (back-patch request)

On Thu, Dec 17, 2015 at 12:31 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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