On Mon, Jul 4, 2016 at 2:31 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > 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: >>> >>>> 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? >
That doesn't sound to be an impressive way to deal. First, visibilitymap_set logs the action itself which will generate two WAL records (one for visibility map and another for lock tuple). Second, it doesn't look consistent to me. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
