On 2015/09/02 15:40, Amit Langote wrote:
> On 2015-09-02 PM 03:25, Amit Kapila wrote:
>> On Wed, Sep 2, 2015 at 11:35 AM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
>>> The UPDATE/DELETE pushdown, which I've proposed, would ensure the sane
>>> behaviour for inherited UPDATEs/DELETEs, as existing non-pushed-down
>>> UPDATE/DELETE does, because inheritance_planner guarantees that all
>>> backends lock inheritance children in the same order to avoid needless
>>> deadlocks.
>> Will it be able to do it for row level locks, row level locking occurs
>> during updation of a row, so will it be possible to ensure the order of
>> locks on rows?
>> 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?
Yeah, I thinks so, too.
Sorry, maybe my explanation above was not enough, but in the inherted
UPDATEs/DELETEs, the table modification is also ensured to be done in
the same order. So, as Amit Langote said, both transactions will do the
updates in the same order.
Best regards,
Etsuro Fujita