Skip site navigation (1) Skip section navigation (2)

Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples
Date: 2013-01-10 02:45:36
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On 8 January 2013 02:49, Noah Misch <noah(at)leadboat(dot)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

Not sure about the skipping WAL records and share locking part, that's
too radical for me.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2013-01-10 02:48:23
Subject: Re: Index build temp files
Previous:From: Noah MischDate: 2013-01-10 02:36:55
Subject: Re: Index build temp files

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group