Re: [HACKERS] UPDATE of partition key
| От | amul sul |
|---|---|
| Тема | Re: [HACKERS] UPDATE of partition key |
| Дата | |
| Msg-id | CAAJ_b975YRWxt8gN5F7HF7bJL+zJHnHo+0b-F0Nfw8gw8Wtg+g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] UPDATE of partition key (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
| Ответы |
Re: [HACKERS] UPDATE of partition key
|
| Список | 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
Вложения
В списке pgsql-hackers по дате отправления: