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

Re: Nested xacts: looking for testers and review

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Nested xacts: looking for testers and review
Date: 2004-05-29 16:36:54
Message-ID: 20040529163654.GA19998@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

>  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.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Ninguna manada de bestias tiene una voz tan horrible como la humana" (Orual)


In response to

Responses

pgsql-hackers by date

Next:From: Stephan SzaboDate: 2004-05-29 16:53:18
Subject: Re: Nested xacts: looking for testers and review
Previous:From: Gaetano MendolaDate: 2004-05-29 16:20:57
Subject: Re: false infinite recursion detected

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