Skip site navigation (1) Skip section navigation (2)

Re: Nested transactions and tuple header info

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Manfred Koizar <mkoi-pg(at)aon(dot)at>,David Blasby <dblasby(at)refractions(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Nested transactions and tuple header info
Date: 2004-06-02 03:50:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jun 01, 2004 at 11:17:40PM -0400, Bruce Momjian wrote:

> Basically the phantom xid's are a shorthand for saying the tuple was
> created by xid1 and deleted by xid2, both part of the same main
> transaction.

Hmm... this would spread the ugliness elsewhere (hopefully only

> A cursor looking at the rows has to recognize the xid is a phantom (via
> pg_subtrans) and look up the creation xid.

No need to look at pg_subtrans because we know all the Xids of our
transaction tree.  I think this can be kept in local memory.

> Also, we will need a phantom xid for every xid1/xid2 pair.  You can't
> just create one phantom xid per subtransaction because you must be able
> to control independently commit/rollback rows based on the status of the
> insert transaction.

Oh, sure.  This could get huge pretty fast.

We still need to think on the effects this could have on crash recovery
though -- we'd have to write the phantom Xids to Xlog somehow
(indicating which ones are committed and which are aborted).  And we
still don't know what effect it would have on CPU cost for every
visibility check.

Alvaro Herrera (<alvherre[a]>)
"Los dioses no protegen a los insensatos.  Éstos reciben protección de
otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2004-06-02 03:53:39
Subject: Re: Why repalloc() != realloc() ?
Previous:From: Bruce MomjianDate: 2004-06-02 03:50:13
Subject: Re: Nested transactions and tuple header info

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group