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@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