On Tue, Jun 28, 2016 at 8:06 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > On Tue, Jun 21, 2016 at 6:59 AM, Andres Freund <and...@anarazel.de> wrote: >> On 2016-06-20 17:55:19 -0400, Robert Haas wrote: >>> 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. >> >> Consider what happens if we, after restarting at l2, notice that we >> can't actually insert, but return in the !HeapTupleMayBeUpdated >> branch. If the caller doesn't error out - and there's certainly callers >> doing that - we'd "leak" a toasted datum. > > Sorry for interrupt you, but I have a question about this case. > Is there case where we back to l2 after we created toasted > datum(called toast_insert_or_update)? > IIUC, after we stored toast datum we just insert heap tuple and log > WAL (or error out for some reasons). >
I understood now, sorry for the noise. Regards, -- Masahiko Sawada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
