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: http://www.postgresql.org/mailpref/pgsql-hackers
