Re: HOT patch - version 15

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: HOT patch - version 15
Дата
Msg-id 2e78013d0709132045x327330f0gc07accd5aae6bde0@mail.gmail.com
обсуждение исходный текст
Ответ на Re: HOT patch - version 15  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches


On 9/14/07, Tom Lane <tgl@sss.pgh.pa.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

В списке pgsql-patches по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Reduce the size of PageFreeSpaceInfo on 64bit platform
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] PAM authentication fails for local UNIX users