On Mon, Jun 20, 2016 at 4:24 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-06-20 16:10:23 -0400, Robert Haas wrote: >> What exactly is the point of all of that already_marked stuff? > > Preventing the old tuple from being locked/updated by another backend, > while unlocking the buffer. > >> I >> mean, suppose we just don't do any of that before we go off to do >> toast_insert_or_update and RelationGetBufferForTuple. Eventually, >> when we reacquire the page lock, we might find that somebody else has >> already updated the tuple, but couldn't that be handled by >> (approximately) looping back up to l2 just as we do in several other >> cases? > > We'd potentially have to undo a fair amount more work: the toasted data > would have to be deleted and such, just to retry. Which isn't going to > super easy, because all of it will be happening with the current cid (we > can't just increase CommandCounterIncrement() for correctness reasons).
Why would we have to delete the TOAST data? AFAIUI, the tuple points to the TOAST data, but not the other way around. So if we change our mind about where to put the tuple, I don't think that requires re-TOASTing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
