Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 41E179FB388 for ; Wed, 24 Jan 2007 10:10:00 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 78670-07 for ; Wed, 24 Jan 2007 10:09:44 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from stark.enterprisedb.com (unknown [62.232.55.118]) by postgresql.org (Postfix) with ESMTP id 86E639FB5A5 for ; Wed, 24 Jan 2007 10:09:49 -0400 (AST) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with esmtp (Exim 4.63) (envelope-from ) id 1H9io0-00068e-7g; Wed, 24 Jan 2007 14:08:52 +0000 From: Gregory Stark To: "Pavan Deolasee" Cc: "Martijn van Oosterhout" , "Tom Lane" , Subject: Re: Free space management within heap page In-Reply-To: <2e78013d0701240509i4b373516s47f80194f73c6@mail.gmail.com> (Pavan Deolasee's message of "Wed, 24 Jan 2007 18:39:48 +0530") Organization: EnterpriseDB 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> X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX" 5584) Date: Wed, 24 Jan 2007 14:08:51 +0000 Message-ID: <877ivcecuk.fsf@stark.xeocode.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/1128 X-Sequence-Number: 97029 "Pavan Deolasee" writes: > On 1/24/07, Martijn van Oosterhout 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