Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples
Date
Msg-id CAMkU=1wU9vRfVG3tt-J1QvXJeduyc7mJY7PuL37PaYsAOXw+sg@mail.gmail.com
Whole thread Raw
In response to Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples  (Noah Misch <noah@leadboat.com>)
Responses Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples
List pgsql-hackers
On Wednesday, January 9, 2013, Noah Misch wrote:
On Thu, Jan 10, 2013 at 02:45:36AM +0000, Simon Riggs wrote:
> On 8 January 2013 02:49, Noah Misch <noah@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.

That works, too.

As bug fixes don't usually go through the commit-fest process, will someone be committing one of these two ideas for the back-branches?  And to HEAD, in case the more invasive patch doesn't make it in?

I have a preliminary nit-pick on the big patch.  It generates a compiler warning:

vacuumlazy.c: In function ‘lazy_scan_heap’:
vacuumlazy.c:445:9: warning: variable ‘prev_dead_count’ set but not used [-Wunused-but-set-variable]


Thanks,

Jeff

pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: ALTER command reworks
Next
From: Tom Lane
Date:
Subject: Re: pg_dump transaction's read-only mode