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

Re: Nested Transaction TODO list

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Nested Transaction TODO list
Date: 2004-07-03 16:30:28
Message-ID: 21364.1088872228@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> On Sat, Jul 03, 2004 at 11:03:33AM -0400, Tom Lane wrote:
>> What about reporting transaction state/nesting level to client?  I did not
>> like the GUC-variable approach in the original patch, partly on grounds of
>> efficiency and partly because I doubt it works under transaction-failure
>> conditions.  I'm inclined to think we need a small protocol change.
>> Perhaps it would work to add an additional field to Z messages that is
>> only sent when nest level > 1.

> It's a shame to have to lose backwards compatibility.

I don't like using ParameterStatus because it's not designed for dealing
with values that may change many times in a single query.  Also it sends
strings, which this really isn't.

I haven't looked at JDBC, but at least in the libpq code, what we could
safely do is extend the existing no transaction/in transaction/in failed
transaction field to provide a five-way distinction: those three cases
plus in subtransaction/in failed subtransaction.  You could not directly
tell the depth of your subxact from this, but do you need to?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Greg Sabino MullaneDate: 2004-07-03 16:36:36
Subject: Re: Creating a selective aggregate ??
Previous:From: Alvaro HerreraDate: 2004-07-03 16:10:21
Subject: Re: Nested Transaction TODO list

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