Re: Weird behavior in transaction handling (Possible bug ?)

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Vadim Nasardinov <vadimn(at)redhat(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Weird behavior in transaction handling (Possible bug ?)
Date: 2005-01-14 22:12:16
Message-ID: 41E843C0.2080005@fastcrypt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Vadim Nasardinov wrote:

>On Friday 14 January 2005 16:38, Oliver Jowett wrote:
>
>
>>It might be worthwhile having commit() throw an exception if the
>>transaction did not actually commit, rather than only reporting
>>server-generated errors. What do people think?
>>
>>
>
>Sounds like a good idea.
>
>
>
>>It'd be possible to have optional "automatic savepoint wrapping" in the
>>driver, where every user query was transparently wrapped in
>>subtransaction. You might prefer to write the code to make the driver do
>>this, rather than change your application.
>>
>>
>
>Also seems like a useful feature at first blush.
>
>
>
I'd hope this was optional, I certainly don't want every statement
wrapped in a savepoint.

I see no point in either of these as the solution is simple... Don't
ignore errors.
However I wouldn't argue if the first was implemented. The second is
questionable due to the extra code complexity and the overhead imposed.
How many savepoints can the system handle ? What if I have a huge
transaction ?

Dave

>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>
>
>

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Vadim Nasardinov 2005-01-14 22:27:02 Re: Weird behavior in transaction handling (Possible bug ?)
Previous Message Vadim Nasardinov 2005-01-14 22:07:37 Re: Weird behavior in transaction handling (Possible bug ?)