Re: Free space management within heap page

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Free space management within heap page
Дата
Msg-id 2e78013d0701240509i4b373516s47f80194f73c6@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Free space management within heap page  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: Free space management within heap page  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers

On 1/24/07, Martijn van Oosterhout <kleptog@svana.org> wrote:
On Wed, Jan 24, 2007 at 12:45:53PM +0530, Pavan Deolasee wrote:
> My apologies if this has been discussed before. I went through the earlier
> discussions, but its still very fuzzy to me. I am not able to construct a
> case
> where a tuple is DEAD (not RECENTLY_DEAD) and still there could be
> a transaction need to follow the ctid pointer chain from its parent. Can
> somebody help me to construct this scenario ?

I thought the classical example was a transaction that updated the same
tuple multiple times before committing. Then the version prior to the
transaction start isn't dead yet, but all but one of the versions
created by the transaction will be dead (they were never visible by
anybody else anyway).


I believe that calculation of oldestXmin would consider the running transaction,
if any, which can still see the original tuple. So the intermediate tuples won't be
declared DEAD (they will be declared RECENTLY_DEAD) as long as the other
transaction is running. Any newer transactions would always see the committed
copy and hence need not follow ctid through the dead tuples.

I might be missing something very obvious, but thats what I am trying to
understand.

Thanks,
Pavan

EnterpriseDB     http://www.enterprisedb.com

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

Предыдущее
От: "Luis D. García"
Дата:
Сообщение: Re: Searching some sites explaing about PosgtreSQL source codes
Следующее
От: "Zeugswetter Andreas ADI SD"
Дата:
Сообщение: Re: Updateable cursors