Re: Horizontal scalability/sharding - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Horizontal scalability/sharding
Date
Msg-id 55E6A7F5.9040504@lab.ntt.co.jp
Whole thread Raw
In response to Re: Horizontal scalability/sharding  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Responses Re: Horizontal scalability/sharding  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
On 2015-09-02 PM 04:07, Albe Laurenz wrote:
> Amit Langote wrote:
>> On 2015-09-02 PM 03:25, Amit Kapila wrote:
>>> Will it handle deadlocks across different table partitions. Consider
>>> a case as below:
>>>
>>> T1
>>> 1. Updates row R1 of T1 on shard S1
>>> 2. Updates row R2 of T2 on shard S2
>>>
>>> T2
>>> 1. Updates row R2 of T2 on shard S2
>>> 2. Updates row R1 of T1 on shard S1
> 
>> As long as shards are processed in the same order in different
>> transactions, ISTM, this issue should not arise? I can imagine it becoming
>> a concern if parallel shard processing enters the scene. Am I missing
>> something?
> 
> 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?

Thanks,
Amit




pgsql-hackers by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: Horizontal scalability/sharding
Next
From: Michael Paquier
Date:
Subject: Re: Fwd: Core dump with nested CREATE TEMP TABLE