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.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?
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
