Re: HOT documentation README

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: HOT documentation README
Date: 2007-09-13 04:45:05
Message-ID: 2e78013d0709122145k6d5ec75auc6f70844541b8182@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On 9/12/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>
>
> This seems all wrong to me. We'd only be considering freezing a tuple
> whose xmin precedes the global xmin. If it has a predecessor, that
> predecessor has xmax equal to this one's xmin, therefore also preceding
> global xmin, therefore it would be seen as DEAD not RECENTLY_DEAD.
> So we should never need to freeze a tuple that isn't the start of its
> HOT chain.

hm.. What you are saying is right. I fail to recollect any other scenario
that
had forced me to think freezing is a problem with HOT.

Also, if you find a DEAD tuple after a RECENTLY_DEAD one, you can
> certainly prune both, because what this tells you is that both tuples
> are in fact dead to all observers.
>
>
I agree. I ran a long test with this change and there doesn't seem to be
any issue. So lets prune everything including the latest DEAD tuple. That
would let us take out the changes related to freezing. I also think that
should let us remove the DEAD_CHAIN concept, but let me check.

Thanks,
Pavan

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

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Teodor Sigaev 2007-09-13 06:55:22 Re: [COMMITTERS] pgsql: Remove QueryOperand->istrue flag, it was used only in cover
Previous Message Bruce Momjian 2007-09-13 03:43:22 Re: [HACKERS] New Zealand - TZ change