On 8 January 2013 02:49, Noah Misch <n...@leadboat.com> wrote: > There is a bug in lazy_scan_heap()'s > bookkeeping for the xid to place in that WAL record. Each call to > heap_page_prune() simply overwrites vacrelstats->latestRemovedXid, but > lazy_scan_heap() expects it to only ever increase the value. I have a > attached a minimal fix to be backpatched. It has lazy_scan_heap() ignore > heap_page_prune()'s actions for the purpose of this conflict xid, because > heap_page_prune() emitted an XLOG_HEAP2_CLEAN record covering them.
Interesting. Yes, bug, and my one of mine also. ISTM the right fix is fix to correctly initialize on pruneheap.c line 176 prstate.latestRemovedXid = *latestRemovedXid; better to make it work than to just leave stuff hanging. I very much like your patch to remove all that cruft altogether; good riddance. I think you're missing removing a few calls to HeapTupleHeaderAdvanceLatestRemovedXid(), perhaps even that routine as well. Not sure about the skipping WAL records and share locking part, that's too radical for me. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers