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

Re: nested transactions

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: Manfred Koizar <mkoi-pg(at)aon(dot)at>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: nested transactions
Date: 2002-11-29 02:35:13
Message-ID: 200211290235.gAT2ZD929284@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I should add that I am not prepared to overhaul the pg_clog file format
> > as part of adding subtransactions for 7.4.  I can do the tid/sequential scan
> > method for abort, or the single-lock method described.
> 
> If you think that changing the pg_clog file format would be harder than
> either of those other ideas, I think you're very badly mistaken.
> pg_clog is touched only by one rather simple module.

Agreed, the clog changes would be the simple solution.  However, I am
not sure I can make that level of changes.  In fact, the complexity of
having multiple transactions per backend is going to be tough for me
too.

Also, I should point out that balooning pg_clog by 16x is going to mean
we are perhaps 4-8x more likely to need extra pages to mark all
subtransactions.

Isn't there some other way we can link these subtransactions together
rather than mucking with pg_clog, as we only need the linkage while we
mark them all committed?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  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

Responses

pgsql-hackers by date

Next:From: Neil ConwayDate: 2002-11-29 02:38:59
Subject: Re: Query performance. 7.2.3 Vs. 7.3
Previous:From: Tom LaneDate: 2002-11-29 02:29:31
Subject: Re: nested transactions

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