Re: HOT synced with HEAD

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: HOT synced with HEAD
Date: 2007-09-16 17:59:06
Message-ID: 2e78013d0709161059j791eb42q8c7325b48b8d2353@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On 9/16/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> BTW, I am still looking for a reason for the hard-prune logic to live.
> It seems to complicate matters far more than it's worth --- in
> particular the way that the WAL replay representation is set up seems
> confusing and fragile. (If prune_hard is set, the "redirect" entries
> mean something completely different.) There was some suggestion that
> VACUUM FULL has to have it, but unless I see proof of that I'm thinking
> of taking it out.

The notion of hard prune has changed since we recently decided to always
prune the chain upto and including the latest DEAD tuple (which includes
the preceding RECENTLY_DEAD tuples). Earlier hard_prune involved
pruning upto the latest DEAD tuple. The only extra thing hard_prune
now does is that it clears the redirected line pointers (I hope I have
fixed the comments to reflect this change; but my apologies if I haven't)

But that seems like a worthy thing to do to me. One because thats the
cheapest (and may be the easiest) way of getting rid of redirected line
pointers and two because that helps us the book-keeping in VACUUM
FULL. You are already finding that complex - with the redirected line
pointers it might be even more complex.

If you are worried about the WAL part, may be we can fix that some
other way.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-09-16 18:16:54 Re: HOT synced with HEAD
Previous Message Tom Lane 2007-09-16 17:40:28 Re: HOT synced with HEAD