Re: UPDATE of partition key

On Fri, Feb 24, 2017 at 3:50 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Feb 24, 2017 at 3:24 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
>> It is of course very good that we have something ready for this
>> release and can make a choice of what to do.
>>
>> Thoughts
>>
>> 1. Reuse the tuple state HEAP_MOVED_OFF which IIRC represent exactly
>> almost exactly the same thing. An UPDATE which gets to a
>> HEAP_MOVED_OFF tuple will know to re-find the tuple via the partition
>> metadata, or I might be persuaded that in-this-release it is
>> acceptable to fail when this occurs with an ERROR and a retryable
>> SQLCODE, since the UPDATE will succeed on next execution.
>
> I've got my doubts about whether we can make that bit work that way,
> considering that we still support pg_upgrade (possibly in multiple
> steps) from old releases that had VACUUM FULL. We really ought to put
> some work into reclaiming those old bits, but there's probably no time
> for that in v10.
>

I agree with you that it might not be straightforward to make it work,
but now that earliest it can go is v11, do we want to try doing
something other than just documenting it. What I could read from this
e-mail thread is that you are intending towards just documenting it
for the first cut of this feature. However, both Greg and Simon are of
opinion that we should do something about this and even patch Author
(Amit Khandekar) has shown some inclination to do something about this
point (return error to the user in some way), so I think we can't
ignore this point.

I think now that we have some more time, it is better to try something
based on a couple of ideas floating in this thread to address this
point and see if we can come up with something doable without a big
architecture change.

What is your take on this point now?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com