Re: HOT patch - version 15

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: HOT patch - version 15
Date: 2007-09-14 03:45:42
Message-ID: 2e78013d0709132045x327330f0gc07accd5aae6bde0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On 9/14/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>
> HeapTupleSatisfiesAbort is bogus because it has failed to track recent
> changes in tqual.c.

Oh. I should have been aware.

Rather than fix it, though, I question why we need it at all. The only
> use of it is in heap_prune_tuplechain() and ISTM that code is redundant,
> wrong, or both.
>
> In the case of a full-page prune, it's redundant because the tuple would
> be found anyway by searching its chain from the root tuple. Indeed I
> suspect that such a tuple is entered into the newly-dead list twice,
> perhaps risking overflow of that array.

No, we would never reach an aborted dead tuple from the chain because
we would see a live tuple before that. Or the tuple preceding the aborted
(first aborted, if there are many) may have been updated again and the
chain never reaches to the aborted tuples. Thats the reason why we have
HeapTupleSatisfiesAbort to collect any aborted heap-only tuples.

In the case of a single-chain prune, it still seems wrong since you'll
> eliminate only one of what might be a chain with multiple aborted
> entries. If it's OK to leave those other entries for future collection,
> then it should be OK to leave this one too. If it's not OK then the
> approach needs to be redesigned.

Again, since we check every heap-only tuple for aborted dead
case we shall collect all such tuples. I think one place where you
are confusing (or IOW the code might have confused you ;-))
is that we never reach aborted dead heap-only tuples by
following the HOT chain from the root tuple and thats why it
needs special treatment.

I'm fairly unclear on what the design intention is for recovering from
> the case where the last item(s) on a HOT chain are aborted. Please
> clarify.
>
>
We don't do anything special. Such a tuple is never reached during
HOT chain following because either we would see a visible tuple before
that or the older tuple might have been updated again and the chain
had moved in a different direction. We only need some special treatment
to prune such tuple and hence the business of HeapTupleSatisfiesAbort

Having said that, based on our recent discussion about pruning a chain
upto and including the latest DEAD tuple in the chain, ISTM that we can
get rid of the giving any special treatment to aborted heap-only
tuples. Earlier we could not do so for "HOT updated aborted heap-only"
because we did not know if its a part of any valid HOT chain. Now
(assuming we change the pruning code to always prune everything including
the latest DEAD tuple) we guarantee that all DEAD tuples in the chain will
be pruned, and hence we can collect any DEAD tuple seen while pruning.

I am not sure if I explain this well, may be I should post an example.
Need to run now.

Thanks,
Pavan

--

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

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2007-09-14 03:53:30 Re: [HACKERS] PAM authentication fails for local UNIX users
Previous Message Bruce Momjian 2007-09-14 03:37:30 Re: Reduce the size of PageFreeSpaceInfo on 64bit platform