On Fri, 28 May 2004, Alvaro Herrera wrote: > On Fri, May 28, 2004 at 05:43:41PM -0700, Stephan Szabo wrote: > > > On Wed, 26 May 2004, Alvaro Herrera wrote: > > > > > 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 unfortunately didn't really follow the discussions in the past (sorry :( > > ), but are the transaction state modifying statements done in a > > subtransaction supposed to live beyond subtransaction rollback? > > Hmm, I suppose not.
Actually, looking at it, for set transaction, the worse one is probably isolation level because it can't be set after a query has been run and I'm not entirely sure what the behavior should look like if you did something like: begin; set transaction isolation level serializable; begin; set transaction isolation level read committed; select * from a; rollback; At that point, is the transaction in serializable method and is the snapshot set even though the select "never happened" and what does the above really mean. Is it that the results of that first transactions are out of serializability with the rest of the transaction? Also related, although START TRANSACTION (specifying isolation level or read onlyness as part) is currently defined to act as if set transaction was used, it seems really odd that the settings would leak to the outer translation even on a commit and that you can't specify isolation level - even if it's the same level - if the outer transaction has done any queries. ----- BTW: For the deferred trigger stuff, I am guessing you haven't touched that at all in the current patch? I wonder if the following would work assuming that we want deferred triggers to run at outer transaction end? -- There's one trigger queue list and a stack of "last event before this (sub)transaction started" pointers in and a current one similar to _imm is the one for the current subtransaction. Scanning the list takes an extra argument to say whether to consolidate the list or not (generally true except for set state). On outer transaction start, NULL is set as the last event at start pointer On subtransaction start, The current last event at start pointer is added to the stack. The last event at start pointer is set to _imm. The _imm pointer should already be in the correct place On subtransaction abort, The queue is deallocated after the last event at start pointer and the event in question its next pointer reset. (if null, the list is entirely deallocated and the list is set as null) The _imm pointer is set to the last event at start pointer. The last event at start pointer is popped from the stack. On outer transaction abort, Clear the queue. On subtransaction commit, The last event at start pointer is popped from the stack. On outer transaction commit Scan the deferred events. On set state, We call DeferredTriggerInvokeEvents with (true, false) rather than relying on the statement end to do it (as true, true). This should set the _imm pointer so that the end of statement won't scan anything anyway. -- I think it might be possible to do the queue deallocation for subtransaction abort with appropriate context work (each one gets a context under its parent's and on abort it's removed and on commit it's not until you reach the outermost?) but I haven't though about it enough. And I think the non-removing events on set transaction could be fixed as well. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
