Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples
Date: 2013-01-19 22:58:32
Message-ID: CAMkU=1wU9vRfVG3tt-J1QvXJeduyc7mJY7PuL37PaYsAOXw+sg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)leadboat(dot)com <javascript:;>>
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-19 22:59:32 Re: pg_dump transaction's read-only mode
Previous Message Kohei KaiGai 2013-01-19 22:48:50 Re: ALTER command reworks