Re: Horizontal scalability/sharding
От | Amit Langote |
---|---|
Тема | Re: Horizontal scalability/sharding |
Дата | |
Msg-id | 55E6C439.8080309@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Horizontal scalability/sharding (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: Horizontal scalability/sharding
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: