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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-05-26 22:17:55 | Re: SELECT * FROM <table> LIMIT 1; is really slow |
Previous Message | David Blasby | 2004-05-26 21:55:27 | Re: SELECT * FROM <table> LIMIT 1; is really slow |