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

Re: Nested transactions and tuple header info

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,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:17:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > 	BEGIN;	xid=1
> > 	INSERT a;
> > 	BEGIN;	xid=2
> > 	INSERT b;
> > 	DELETE a; xid=3
> > 	COMMIT;
> > 	COMMIT;
> > When "DELETE a" happens, we remove the xmin=1 from the tuple header and
> > replace it with xmin=3.
> You can't change xmin --- this would break visibility tests.  Consider
> a cursor opened in the outer transaction after the INSERT a.  It should
> be able to see the "a" row (note that this depends on recognizing xid
> equality and then comparing cid's within the outer transaction).  If the
> subtransaction mangles xmin then it is no longer possible to make this
> test correctly.
> This is exactly the same argument as not being able to overwrite cmin.

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

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

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.

In this case:

		BEGIN;	xid=1
			BEGIN;	xid=2
			INSERT b;
				BEGIN;	xid=3
				DELETE a; xid=4
				DELETE b; xid=5

xid4 and xid5 has to be adjusted based on that status of xid1 and xid2.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2004-06-02 03:39:57
Subject: Re: Why repalloc() != realloc() ?
Previous:From: Bruce MomjianDate: 2004-06-02 03:08:00
Subject: Re: Official Freeze Date for 7.5: July 1st, 2004

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