On 2015-09-02 PM 03:25, Amit Kapila wrote: > On Wed, Sep 2, 2015 at 11:35 AM, Etsuro Fujita <fujita.ets...@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? 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
