On Sat, Jul 2, 2016 at 12:17 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Sat, Jul 2, 2016 at 12:53 AM, Andres Freund <and...@anarazel.de> wrote: >> On 2016-07-01 15:18:39 -0400, Robert Haas wrote: >>> On Fri, Jul 1, 2016 at 10:22 AM, Masahiko Sawada <sawada.m...@gmail.com> >>> wrote: >>> > Ah, you're right, I misunderstood. >>> > >>> > Attached updated patch incorporating your comments. >>> > I've changed it so that heap_xlog_lock clears vm flags if page is >>> > marked all frozen. >>> >>> I believe that this should be separated into two patches, since there >>> are two issues here: >>> >>> 1. Locking a tuple doesn't clear the all-frozen bit, but needs to do so. >>> 2. heap_update releases the buffer content lock without logging the >>> changes it has made. >>> >>> With respect to #1, there is no need to clear the all-visible bit, >>> only the all-frozen bit. However, that's a bit tricky given that we >>> removed PD_ALL_FROZEN. Should we think about putting that back again? >> >> I think it's fine to just do the vm lookup. >> >>> Should we just clear all-visible and call it good enough? >> >> Given that we need to do that in heap_lock_tuple, which entirely >> preserves all-visible (but shouldn't preserve all-frozen), ISTM we >> better find something that doesn't invalidate all-visible. >> > > Sounds logical, considering that we have a way to set all-frozen and > vacuum does that as well. So probably either we need to have a new > API or add a new parameter to visibilitymap_clear() to indicate the > same. If we want to go that route, isn't it better to have > PD_ALL_FROZEN as well? >
Cant' we call visibilitymap_set with all-visible but not all-frozen bits instead of clearing flags? Regards, -- Masahiko Sawada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
