From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | amul sul <sulamul(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key |
Date: | 2018-02-14 12:14:56 |
Message-ID: | CAA4eK1+n4diQ7vNOPNarT=D1yCbG31n2SYCMhJSX2bADHAR+Ow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 13, 2018 at 12:41 PM, amul sul <sulamul(at)gmail(dot)com> wrote:
> On Tue, Feb 13, 2018 at 11:32 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2018-02-14 12:35:00 | Is this a bug? |
Previous Message | Marina Polyakova | 2018-02-14 10:40:00 | Re: master plpython check fails on Solaris 10 |