So correct me if I'm wrong.

even in psql you are getting no error message from the commit statement?

The driver can't possibly know when something is going to fail.

Dave

j.random.programmer wrote:

>>an error. And I don't believe commit fails silently,
>>it should give you
>>an error.
>>
>>
>
>Nope, no error. See the original post, there isn't any
>error
>in the postgresql logs either, and no error at the
>JDBC layer.
>
>
>
>>(notably Oracle). So I would expect you're coming
>>from an oracle DB
>>experience...
>>
>>
>
>Nope. I've been using Postgresql for years now (after
>having
>used mysql/innodb and gotten rather tired of _that_).
>
>:-]
>
>
>
>>Please note that setting a savepoint in postgres is
>>not nearly free, so
>>be careful how often you do it.
>>
>>
>
>After further testing, the standalone psql client also
>shows
>the same behavior so I guess this is a postgresql
>database
>thing, not driver specific.
>
>Here's my humble suggestion. If technically possible,
>have
>the driver throw a SQLExeption when trying to commit()
>
>and when the driver knows that commit() is going to
>fail.
>
>Maybe the driver can simple track if it's recieved any
>kind
>of error messages on a given connection. If so, then
>when
>commit() is called on that connection, the driver
>should
>throw a SQLException ?
>
>Otherwise, you're asking for very esoteric bugs to say
>you have
>commit() succesfully yet fail silently. That's more
>like a mysql
>thing, *not* a postgresql thing right ?
>
>Best regards,
>
>--j
>
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Meet the all-new My Yahoo! - Try it today!
>http://my.yahoo.com
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>
>
>

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

Dave:

>Actually, reviewing your original post. Yes the
commit fails
> silently. However the insert does not fail silently
and should throw
> an error! Do you check for errors here ?

I was simple catching the exception but not rolling
back since
I presumed the rest of the transaction would succeed
(and
commit() didn't complain). It's only after playing
around that I
realized that the transaction was failing because of
the earlier
error.

> So correct me if I'm wrong.
> even in psql you are getting no error message from
> the commit statement?

Here's a psql session
-----------------------------------------------
g=# create table foo (id int primary key, words text);
g=# begin;
g=# insert into foo values (1, 'hello');
g=# insert into foo values (1, 'hello');
ERROR: duplicate key violates unique constraint
"foo_pkey"
g=# end;
COMMIT
g=# select * from foo;
+----+-------+
| id | words |
+----+-------+
+----+-------+
(0 rows)
------------------------------------------------

Note, the first insert failed silently too.

So yeah, this looks like a postgres database specific
thing. But postgres is *better* than that -- the above
behavior is expected from myql BUT NOT postgres, right
?

So maybe, the database folks can do something about
this in version 8.0. Maybe you can also forward this
message
to the core postgres folks ?

> The driver can't possibly know when something is
> going to fail.

It can, since it gets an error back from the database
and "knows" the internal postgresql behavior.

Specifically and in the MEANTIME, why can't you do
the
follwing in the JDBC driver ?

----------- JDBC driver code ------------------

boolean sawExceptionInConnection = false;
String errorMessageInConnection;
.....
if an error is thrown back from the database
then
sawExceptionInConnection = true;
/*the error message that was actually recieved saved
here*/
errorMessageInConnection =
"ERROR: duplicate key violates unique constraint";
.....
in the commit() method implementation

if (sawExceptionInConnection)
throw new SQLException(
"postgres will not allow this commit() to succeed
since an error was recieved from the database.
The error = " + errorMessageInConnection);

----------------------------------------------
Is there any technical reason why the above
cannot/should not
be implemented ? It would be the RIGHT thing to do
since
it would get rid of SILENT failure (which is
absolutely, utterly
wrong in any database).

Best regards,

--j




__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

On January 14, 2005 01:51 pm, j.random.programmer wrote:
[...]
> I was simple catching the exception but not rolling
> back since
> I presumed the rest of the transaction would succeed
> (and
> commit() didn't complain). It's only after playing
> around that I
> realized that the transaction was failing because of
> the earlier
> error.
>
[...]
>
> So maybe, the database folks can do something about
> this in version 8.0. Maybe you can also forward this
> message
> to the core postgres folks ?
>

I *strongly* disagree. As mentioned before, a transaction is supposed to be an
*atomic* unit of work; either it succeeds completely or it's not executed at
all. Consider the canonical example of a transaction: money being tranfered
from one account to another. You don't want one update to be committed if the
other failed.

JdV!!


--
--------------------------------------------------------------
Jan de Visser jdevisser@digitalfairway.com

Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org