On Mon, May 29, 2017 at 11:20 AM, Amit Khandekar <amitdkhan.pg@gmail.com> wrote:
> On 24 May 2017 at 20:16, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Wed, May 24, 2017 at 8:14 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>> Apart from above, there is one open issue [1]
>>>
>>
>> Forget to mention the link, doing it now.
>>
>> [1] - https://www.postgresql.org/message-id/CAA4eK1KEZQ%2BCyXbBzfn1jFHoEfa_OemDLhLyy7xfD1QUZLo1DQ%40mail.gmail.com
>
> I am not sure right now whether making the t_ctid of such tuples to
> Invalid would be a right option, especially because I think there can
> be already some other meaning if t_ctid is not valid.
>
AFAIK, this is used to point to current tuple itself or newer version
of a tuple or is used in speculative inserts (refer comments above
HeapTupleHeaderData in htup_details.h). Can you mention what other
meaning are you referring here for InvalidBlockId in t_ctid?
> But may be we
> can check this more.
>
> If we decide to error out using some way, I would be inclined towards
> considering re-using some combinations of infomask bits (like
> HEAP_MOVED_OFF as suggested upthread) rather than using invalid t_ctid
> value.
>
> But I think, we can also take step-by-step approach even for v11. If
> we agree that it is ok to silently do the updates as long as we
> document the behaviour, we can go ahead and do this, and then as a
> second step, implement error handling as a separate patch. If that
> patch does not materialize, we at least have the current behaviour
> documented.
>
I think that is sensible approach if we find the second step involves
big or complicated changes.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
