From: Gregory Stark <stark@enterprisedb.com>
To: Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: Martijn van Oosterhout <kleptog@svana.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Free space management within heap page
Date: Wed, 24 Jan 2007 14:08:51 +0000
Message-ID: <877ivcecuk.fsf@stark.xeocode.com> (raw)
In-Reply-To: <2e78013d0701240509i4b373516s47f80194f73c6@mail.gmail.com>
References: <2e78013d0701230018m7bebdd35t32bdc8ea786511e8@mail.gmail.com>
<20070123084846.GC19527@svana.org>
<2e78013d0701230103y1d587db9q6733adca0ca92ca0@mail.gmail.com>
<18259.1169563079@sss.pgh.pa.us>
<2e78013d0701232315s50edcabet95ea44285498e996@mail.gmail.com>
<20070124105350.GA20752@svana.org>
<2e78013d0701240509i4b373516s47f80194f73c6@mail.gmail.com>
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> On 1/24/07, Martijn van Oosterhout <kleptog@svana.org> wrote:
>>
>> 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.
Martijn is correct that HeapTupleSatisfiesVacuum considers tuples dead if
there were created and deleted by the same transaction even if that
transaction isn't past the oldestxmin horizon.
There's already been one bug in that area when it broke update chains, and to
fix it vacuum ignores tuples that were deleted by the same transaction in an
UPDATE statement.
This seems like such an unusual case, especially now that it's been narrowed
by that exception, that it's silly to optimize for it. Just treat these tuples
as live and they'll be vacuumed when their transaction commits and passes the
oldestxmin like normal.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: stark@enterprisedb.com, pavan.deolasee@gmail.com, kleptog@svana.org, tgl@sss.pgh.pa.us
Subject: Re: Free space management within heap page
In-Reply-To: <877ivcecuk.fsf@stark.xeocode.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox