From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Reviewing freeze map code
Date: Mon, 20 Jun 2016 14:59:43 -0700
Message-ID: <20160620215943.73hekh5phsq65uk5@alap3.anarazel.de> (raw)
In-Reply-To: <CA+TgmobpkmbNd5HCwYyKu0rMcL3mzEYM78689-Wh=FJFY9BuOw@mail.gmail.com>
References: <CA+TgmoYOHNANcr503GDoxwyynLHBwgWeB-6sGF2ikBb=sMQLjw@mail.gmail.com>
<CA+Tgmoan8=YLen3SvJ8Qt51fYALmrkULfvhvPcFvNzrHEMSXAA@mail.gmail.com>
<CA+Tgmob+jC=3LUSSQ0ojA02naKC6yb8ny-SHZp8rEFi8Y-X=BA@mail.gmail.com>
<CAEepm=3kJ-fo9UTf6_4HMsKAHgooPXXFDxDF=jQVehiLx-0Bdw@mail.gmail.com>
<CAEepm=2at9oWWqt-eMxz3rw3stSa+m6LRzeM+J+iXKBkUJx9FQ@mail.gmail.com>
<CA+TgmoZ-1TXCsxWcp3i-KMo5DNB-6p-odqw7c-N_q3pzZY1TJg@mail.gmail.com>
<20160620193302.s4dbul6japgar5eg@alap3.anarazel.de>
<CA+TgmobBaJtjQxM0vNbTcUbZ1Buai6a9aTk4b4yt3gNKGPUe-A@mail.gmail.com>
<20160620202453.zg66rvbhmvzl7ihn@alap3.anarazel.de>
<CA+TgmobpkmbNd5HCwYyKu0rMcL3mzEYM78689-Wh=FJFY9BuOw@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2016-06-20 17:55:19 -0400, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:24 PM, Andres Freund <andres@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. Unless the transaction aborts,
the toasted datum would never be cleaned up, because there's no datum
pointing to it, so no heap_delete will ever recurse into the toast
datum (via toast_delete()).
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, robertmhaas@gmail.com, thomas.munro@enterprisedb.com, alvherre@2ndquadrant.com, amit.kapila16@gmail.com, sfrost@snowman.net, michael.paquier@gmail.com, sawada.mshk@gmail.com
Subject: Re: Reviewing freeze map code
In-Reply-To: <20160620215943.73hekh5phsq65uk5@alap3.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox