Re: Horizontal scalability/sharding

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: Horizontal scalability/sharding
Дата
Msg-id 55E6AE3B.8090908@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Horizontal scalability/sharding  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: Horizontal scalability/sharding  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Re: Horizontal scalability/sharding  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On 2015/09/02 16:40, Amit Langote wrote:
> 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?

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*.

Best regards,
Etsuro Fujita




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Fwd: Core dump with nested CREATE TEMP TABLE
Следующее
От: Amit Langote
Дата:
Сообщение: Re: ON CONFLICT DO UPDATE using EXCLUDED.column gives an error about mismatched types