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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
