On 2015-09-02 PM 05:07, Etsuro Fujita wrote:
> On 2015/09/02 16:40, Amit Langote wrote:
>> On 2015-09-02 PM 04:07, Albe Laurenz wrote:
>>>
>>> That would only hold for a single query, right?
>>>
>>> If 1. and 2. in the above example come from different queries within one
>>> transaction, you cannot guarantee that shards are processed in the same
>>> order.
>>>
>>> So T1 and T2 could deadlock.
>
>> Sorry, I failed to see why that would be the case. Could you elaborate?
>
> I think Laurenz would assume that the updates 1. and 2. in the above
> transactions are performed *in a non-inherited manner*. If that's right,
> T1 and T2 could deadlock, but I think we assume here to run transactions
> over shards *in an inherited manner*.
>
I think Albe may have a point here...
Even inherited updates case appears to cause a deadlock if they are in
different queries. Demonstrated below:
-- setup
CREATE TABLE t(a int);
CREATE TABLE t1() INHERITS(t);
CREATE TABLE t2() INHERITS(t);
INSERT INTO t1 VALUES (1);
INSERT INTO t2 VALUES (2);
-- in session 1
BEGIN;
UPDATE t SET a = a + 1 WHERE a = 1;
<ok>
-- in session 2
BEGIN;
UPDATE t SET a = a + 1 WHERE a = 2;
<ok>
-- back in session 1
UPDATE t SET a = a + 1 WHERE a = 2;
<waits>
-- back in session 2
UPDATE t SET a = a + 1 WHERE a = 1;
<deadlock is detected>
Thanks,
Amit
