Peter Geoghegan <p...@heroku.com> writes:
> On Sun, Oct 23, 2016 at 1:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> "Rarely" is not "never". A bigger problem though is that heap_fetch
>> does more than just lock the buffer: there are also PredicateLockTuple
>> and CheckForSerializableConflictOut calls in there. It's possible that
>> those are no-ops in this usage (because after all we already fetched
>> the tuple once), or maybe they're even desirable because they would help
>> resolve Kevin's concerns. But it hasn't been analyzed and so I'm not
>> prepared to risk a behavioral change in this already under-tested area
>> the day before a release wrap.
> I'm surprised at how you've assessed the risk here.
What's bothering me is (a) it's less than 24 hours to release wrap and
(b) this patch changes SSI-relevant behavior and hasn't been approved
by Kevin. I'm not familiar enough with that logic to commit a change
in it on my own authority, especially with so little time for problems
to be uncovered.
I'm okay with adding an explicit buffer lock/unlock pair, and in fact
plan to go have a look at that in a bit. I'm not okay with doing a
refactoring that might change the behavior in more ways than that
under these circumstances.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
