Re: Nested xacts: looking for testers and review
От | Stephan Szabo |
---|---|
Тема | Re: Nested xacts: looking for testers and review |
Дата | |
Msg-id | 20040529094816.A27817@megazone.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Nested xacts: looking for testers and review (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
Список | pgsql-hackers |
On Sat, 29 May 2004, Alvaro Herrera wrote: > On Sat, May 29, 2004 at 08:25:27AM -0700, Stephan Szabo wrote: > > > 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. > > Hmm ... isolation level and read onlyness was discussed last year and I > think we had a working design. I'll look into my archives. > > > > 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? > > Ah, this seems to work. I'll implement it and I'll let you know how it > goes. Note, that I think you'd still need to do some kind of tiered thing for set constraint status, but I didn't think about that yet. > > 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. > > Actually there already is such a global context and I think it's appropiate > here. We probably want to be able to easily remove all the items for an aborted sub transaction, and I was hoping that there might be an easy way to use the contexts to do that rather than manually trolling through deallocating entries from the queue.
В списке pgsql-hackers по дате отправления: