Re: On conflict update & hint bits
От | Tom Lane |
---|---|
Тема | Re: On conflict update & hint bits |
Дата | |
Msg-id | 30037.1477259205@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: On conflict update & hint bits (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: On conflict update & hint bits
|
Список | pgsql-hackers |
Peter Geoghegan <pg@heroku.com> writes: > On Sun, Oct 23, 2016 at 1:42 PM, Tom Lane <tgl@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
В списке pgsql-hackers по дате отправления: