Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: amul sul <sulamul@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-02-14T12:14:56Z
Lists: pgsql-hackers
On Tue, Feb 13, 2018 at 12:41 PM, amul sul <sulamul@gmail.com> wrote: > On Tue, Feb 13, 2018 at 11:32 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> >> Your change appears fine to me. I think one can set both block number >> and offset as we do for HeapTupleHeaderIsSpeculative, but the way you >> have done it looks good to me. Kindly include it in the next version >> of your patch by adding the missing comment. >> > > Thanks for the confirmation, updated patch attached. > +# Concurrency error from GetTupleForTrigger +# Concurrency error from ExecLockRows I think you don't need to mention above sentences in spec files. Apart from that, your patch looks good to me. I have marked it as Ready For Committer. Notes for Committer - 1. We might need some changes in update-tuple-routing mechanism if we decide to do anything for the bug [1] discussed in the nearby thread, but as that is not directly related to this patch, we can move ahead. 2. I think it is better to document that for update tuple routing the delete+insert will be replayed separately on replicas. I leave this to the discretion of the committer. [1] - https://www.postgresql.org/message-id/CAAJ_b94bYxLsX0erZXVH-anQPbWqcYUPWX4xVRa1YJY%3DPh60ZQ%40mail.gmail.com -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Raise error when affecting tuple moved into different partition.
- f16241bef7cc 11.0 landed
-
Handle INSERT .. ON CONFLICT with partitioned tables
- 555ee77a9668 11.0 cited
-
Change the way we mark tuples as frozen.
- 37484ad2aace 9.4.0 cited