Re: Reviewing freeze map code - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Reviewing freeze map code
Date
Msg-id 20160620202453.zg66rvbhmvzl7ihn@alap3.anarazel.de
Whole thread Raw
In response to Re: Reviewing freeze map code  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Reviewing freeze map code  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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).

Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 10.0
Next
From: "David G. Johnston"
Date:
Subject: Re: 10.0