Hi,
On 2013-12-17 18:27:26 -0300, Alvaro Herrera wrote:
> > Well, it would help if those cases weren't dead code. Neither
> > heap_update nor heap_delete are ever called in the "no wait" case at
> > all.
Yea, that sucks, maybe we ought to change that in HEAD. But there very
well might be external callers that use it, I don't think we can just
break the API in a stable release.
> > Only heap_lock_tuple is, and I can't see any misbehavior there
> > either, even with HeapTupleBeingUpdated returned when there's a
> > non-local locker, or when there's a MultiXact as xmax, regardless of its
> > status.
>
> I spent some more time trying to generate a test case that would show a
> problem with the changed return values here, and was unable to.
>
> I intend to apply this patch soon.
I have to say, it makes me really uncomfortable to take such
shortcuts. In other branches we are doing liveliness checks with
MultiXactIdIsRunning() et al. Why isn't that necessary here? And how
likely is that this won't cause breakage somewhere down the line because
somebody doesn't know of that subtlety?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
