On Mon, May 29, 2017 at 11:20 AM, Amit Khandekar <amitdkhan...@gmail.com> wrote:
> On 24 May 2017 at 20:16, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Wed, May 24, 2017 at 8:14 PM, Amit Kapila <amit.kapil...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to