Received: from localhost (maia-3.hub.org [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id D66CD9FB5BF
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Wed, 24 Jan 2007 06:54:18 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024)
	with ESMTP id 99060-05 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Wed, 24 Jan 2007 06:54:09 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from svana.org (calyx.svana.org [125.62.87.134])
	by postgresql.org (Postfix) with ESMTP id 967289FB565
	for <pgsql-hackers@postgresql.org>;
	Wed, 24 Jan 2007 06:54:12 -0400 (AST)
Received: from kleptog by svana.org with local (Exim 4.50)
	id 1H9flG-0005Xv-3m; Wed, 24 Jan 2007 21:53:50 +1100
Date: Wed, 24 Jan 2007 11:53:50 +0100
From: Martijn van Oosterhout <kleptog@svana.org>
To: Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: Free space management within heap page
Message-ID: <20070124105350.GA20752@svana.org>
Reply-To: Martijn van Oosterhout <kleptog@svana.org>
References: <2e78013d0701230018m7bebdd35t32bdc8ea786511e8@mail.gmail.com>
	<20070123084846.GC19527@svana.org>
	<2e78013d0701230103y1d587db9q6733adca0ca92ca0@mail.gmail.com>
	<18259.1169563079@sss.pgh.pa.us>
	<2e78013d0701232315s50edcabet95ea44285498e996@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf"
Content-Disposition: inline
In-Reply-To: <2e78013d0701232315s50edcabet95ea44285498e996@mail.gmail.com>
X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6
X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522  48A7 6394 F08A 0DC6 7BE6
X-PGP-Key-URL: <http://svana.org/kleptog/0DC67BE6.pgp.asc>
User-Agent: Mutt/1.5.9i
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: kleptog@svana.org
X-SA-Exim-Scanned: No (on svana.org); SAEximRunCond expanded to false
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200701/1123
X-Sequence-Number: 97024


--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 beleive other such corner cases are transactions that have
subtransactions that aborted after updating.

But I'm not that knowledgable on MVCC to be sure about that.

Have a nice day,
--=20
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to l=
itigate.

--zhXaljGHf11kAtnf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFtzq9IB7bNG8LQkwRAvd1AJ4hPJz2cfsGraReuj/Lvdgvq8MnEACeIkiH
ZX07dKdLKtMgFy9u8R8NqzI=
=5SfN
-----END PGP SIGNATURE-----

--zhXaljGHf11kAtnf--