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. 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. Ideally, I think we would have liked if we were somehow able to make the row-movement UPDATE itself abort if it finds any normal updates waiting for it to finish, rather than making the normal updates fail because a row-movement occurred . But I think we will have to live with it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
