On Wed, Jun 29, 2016 at 10:30 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-06-29 19:04:31 +0530, Amit Kapila wrote: >> There is nothing in this record which recorded the information about >> visibility clear flag. > > I think we can actually defer the clearing to the lock release?
How about the case if after we release the lock on page, the heap page gets flushed, but not vm and then server crashes? After recovery, vacuum will never consider such a page for freezing as the vm bit still says all_frozen. Another possibility could be that WAL for xl_heap_lock got flushed, but not the heap page before crash, now after recovery, it will set the tuple with appropriate infomask and other flags, but the heap page will still be marked as ALL_VISIBLE. I think that can lead to a situation which Thomas Munro has reported upthread. All other cases in heapam.c, after clearing vm and corresponding flag in heap page, we are recording the same in WAL. Why to make this a different case and how is it safe to do it here and not at other places. > A tuple > being locked doesn't require the vm being cleared. > > >> I think in this approach, it is important to measure the performance >> of update, may be you can use simple-update option of pgbench for >> various workloads. Try it with different fill factors (-F fillfactor >> option in pgbench). > > Probably not sufficient, also needs toast activity, to show the really > bad case of many lock releases. Okay, makes sense. -- 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
