On 2016-07-14 18:12:42 +0530, Amit Kapila wrote:
> Just thinking out loud. If we set HEAP_XMAX_LOCK_ONLY during update,
> then won't it impact the return value of
> HeapTupleHeaderIsOnlyLocked(). It will start returning true whereas
> otherwise I think it would have returned false due to in_progress
> transaction. As HeapTupleHeaderIsOnlyLocked() is being used at many
> places, it might impact those cases, I have not checked in deep
> whether such an impact would cause any real issue, but it seems to me
> that some analysis is needed there unless you think we are safe with
> respect to that.
I don't think that's an issue: Right now the row will be considered
deleted in that moment, with the change it's considered locked. the
latter is surely more appropriate.
> > Any arguments against?
> >
> >>
> >> + /* Clear only the all-frozen bit on visibility map if needed
> >> */
> >> + if (PageIsAllVisible(BufferGetPage(buffer)) &&
> >> + VM_ALL_FROZEN(relation, block, &vmbuffer))
> >> + {
> >> + visibilitymap_clear_extended(relation, block,
> >> vmbuffer,
> >> +
> >> VISIBILITYMAP_ALL_FROZEN);
> >> + }
> >> +
> >
> > FWIW, I don't think it's worth introducing visibilitymap_clear_extended.
> > As this is a 9.6 only patch, i think it's better to change
> > visibilitymap_clear's API.
> >
> > Unless somebody protests I'm planning to commit with those adjustments
> > tomorrow.
> >
>
> Do you think performance tests done by Sawada-san are sufficient to
> proceed here?
I'm doing some more, but generally yes. I also don't think we have much
of a choice anyway.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
