Re: HOT documentation README

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


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

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] New Zealand - TZ change
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Remove QueryOperand->istrue flag, it was used only in cover