Re: [HACKERS] UPDATE of partition key - Mailing list pgsql-hackers

From amul sul
Subject Re: [HACKERS] UPDATE of partition key
Date
Msg-id CAAJ_b975YRWxt8gN5F7HF7bJL+zJHnHo+0b-F0Nfw8gw8Wtg+g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] UPDATE of partition key  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: [HACKERS] UPDATE of partition key
List pgsql-hackers
On Thu, May 18, 2017 at 9:13 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
 On Wed, May 17, 2017 at 5:17 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, May 17, 2017 at 6:29 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> I think we can do this even without using an additional infomask bit.
>> As suggested by Greg up thread, we can set InvalidBlockId in ctid to
>> indicate such an update.
>
> Hmm.  How would that work?
>

We can pass a flag say row_moved (or require_row_movement) to
heap_delete which will in turn set InvalidBlockId in ctid instead of
setting it to self. Then the ExecUpdate needs to check for the same
and return an error when heap_update is not successful (result !=
HeapTupleMayBeUpdated).  Can you explain what difficulty are you
envisioning?


Attaching WIP patch incorporates the above logic, although I am yet to check
all the code for places which might be using ip_blkid.  I have got a small query here,
do we need an error on HeapTupleSelfUpdated case as well?

Note that patch should be applied to the top of Amit Khandekar's latest patch(v17_rebased).

Regards,
Amul

Attachment

pgsql-hackers by date:

Previous
From: Rafia Sabih
Date:
Subject: Re: [HACKERS] Parallel Append implementation
Next
From: Jeevan Chalke
Date:
Subject: Re: [HACKERS] Partition-wise aggregation/grouping