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

Nested xacts: looking for testers and review

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Nested xacts: looking for testers and review
Date: 2004-05-26 22:03:41
Message-ID: 20040526220340.GA24890@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
Hackers,

Ok, I've finally coded solutions to most problems regarding nested
transactions.  This means:

- reversing for the lock manager, catcache, relcache, buffer manager,
  asynchronous notifies, storage manager.

- transaction block state support, including appropiate XLog recording

- pg_subtrans subsystem (including changing state from SUBTRANS
  COMMITTED to COMMITTED when appropiate).  Also pg_clog XLog recovery
  was handed to SLRU so pg_subtrans and pg_clog share a rmgr identity.

- visibility rules.

I'm missing one item: deferred triggers.  The problem with this is that
the deftrig queue is not implemented using normal Lists, so there's no
efficient way to reassign to the parent when the subtransaction commits.
Also I'm not sure what should happen to the "immediate" pointer --- a
subtransaction should have it's own private copy, or it should inherit
the parent's?  Please whoever implemented this speak up (Stephan
Szabo?), as I'm not sure of the semantics.


I have tested it and it passes all regression tests (including ones I
added), plus some more tests I threw at it mainly for concurrency.
Everything behaves as expected.  At this time I'd like to have it
reviewed by the critic eye of the committers, and tested by whoever
would be using it.

I'm open for comments and suggestions and general input.  Thank you.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
La web junta la gente porque no importa que clase de mutante sexual seas,
tienes millones de posibles parejas. Pon "buscar gente que tengan sexo con
ciervos incendiánse", y el computador dirá "especifique el tipo de ciervo"
(Jason Alexander)


Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-05-26 22:17:55
Subject: Re: SELECT * FROM <table> LIMIT 1; is really slow
Previous:From: David BlasbyDate: 2004-05-26 21:55:27
Subject: Re: SELECT * FROM <table> LIMIT 1; is really slow

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