From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Nested transactions |
Date: | 2003-03-25 04:37:35 |
Message-ID: | 20030325043735.GD10643@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hackers,
I've been playing with nested transactions. In fact I have already have
some things working, but there are some major complications I had not
seen.
First is the management of Snapshots (SnapshotDirty, QuerySnapshot,
SerializableSnapshot). They are kept in global variables for each
backend. Then there are DeferredTrigger objects, that are also global
objects.
For MemoryContexts I have put a member in the TransactionStateData
structure. Maybe this is also workable for DeferredTrigger and
Snapshots?
Another idea would be using Lists for each object, managing them as
global stacks. For DeferredTriggers, I could instead add the Xid to the
DeferredTriggerEventItem (DeferredTriggerEventData?) struct, and check
it in deferredTriggerInvokeEvents().
Is there another way? What do people prefer?
Also, about deferred triggers: should they be deferred until toplevel
transaction commit, or only until their calling transaction commits?
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La conclusion que podemos sacar de esos estudios es que
no podemos sacar ninguna conclusion de ellos" (Tanenbaum)
From | Date | Subject | |
---|---|---|---|
Next Message | Shridhar Daithankar | 2003-03-25 05:27:26 | Re: Threaded Python vs. PostGreSQL plpython |
Previous Message | Neil Conway | 2003-03-25 04:01:38 | Re: updateable cursors & visibility |