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

Shouldn't "aborted transaction" be an ERROR? (was Re: [NOVICE] Optimising inside transactions)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Taylor <postgres(at)jtresponse(dot)co(dot)uk>
Cc: pgsql-hackers(at)postgreSQL(dot)org, pgsql-jdbc(at)postgreSQL(dot)org
Subject: Shouldn't "aborted transaction" be an ERROR? (was Re: [NOVICE] Optimising inside transactions)
Date: 2002-06-12 16:12:50
Message-ID: 10426.1023898370@sss.pgh.pa.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackerspgsql-jdbcpgsql-novice
John Taylor <postgres(at)jtresponse(dot)co(dot)uk> writes:
> On Wednesday 12 June 2002 16:36, Tom Lane wrote:
>> Queries after the failure aren't run at all; they're only passed through
>> the parser's grammar so it can look for a COMMIT or ROLLBACK command.
>> Normal processing resumes after ROLLBACK.  If you were paying attention
>> to the return codes you'd notice complaints like
>> 
>> regression=# begin;
>> BEGIN
>> regression=# select 1/0;
>> ERROR:  floating point exception! The last floating point operation either exceeded legal ranges or was a divide by zero
>> -- subsequent queries will be rejected like so:
>> regression=# select 1/0;
>> WARNING:  current transaction is aborted, queries ignored until end of transaction block
>> *ABORT STATE*

> Well, I'm using JDBC, and it isn't throwing any exceptions, so I
> assumed it was working :-/ 

This brings up a point that's bothered me in the past.  Why is the
"queries ignored" response treated as a NOTICE and not an ERROR?
A client that is not paying close attention to the command result code
(as JDBC is evidently not doing :-() might think that its command had
been executed.

It seems to me the right behavior is

regression=# select 1/0;
ERROR:  current transaction is aborted, queries ignored until end of transaction block
regression=# 

I think the reason why it's been done with a NOTICE is that if we
elog(ERROR) on the first command of a query string, we'll not be able to
process a ROLLBACK appearing later in the same string --- but that
behavior does not seem nearly as helpful as throwing an error.

			regards, tom lane

In response to

Responses

pgsql-novice by date

Next:From: Manfred KoizarDate: 2002-06-12 18:14:13
Subject: Re: Optimising inside transactions
Previous:From: John TaylorDate: 2002-06-12 15:42:46
Subject: Re: Optimising inside transactions

pgsql-hackers by date

Next:From: David FordDate: 2002-06-12 16:21:48
Subject: Re: PostGres Doubt
Previous:From: Ulrich NeumannDate: 2002-06-12 16:08:38
Subject: Antw: PostgreSQL and Novell Netware

pgsql-jdbc by date

Next:From: Manfred KoizarDate: 2002-06-12 18:14:13
Subject: Re: Optimising inside transactions
Previous:From: John TaylorDate: 2002-06-12 15:42:46
Subject: Re: Optimising inside transactions

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